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Предисловие от автора, или зачем нужна эта книга 


Выражаю огромную благодарность коллегам из 
ЕРАМ Software Testing Division за ценные замечания 
и рекомендации в процессе подготовки материала. 


Особую благодарность выражаю тем тысячам 
читателей, которые присылали вопросы, пожелания, 
замечания — благодаря вашему вкладу книга стала лучше. 


В основу этой книги положен пятнадцатилетний опыт проведения тренингов 
для тестировщиков. За это время накопилась огромная коллекция вопросов от слу- 
шателей, и стали отчётливо видны типичные для многих начинающих проблемы и 
сложности. Представляется разумным обобщить этот материал в виде книги, кото- 
рая поможет начинающим тестировщикам быстрее погрузиться в профессию и из- 
бежать многих досадных ошибок. 


С момента выхода первого и второго изданий в книгу было внесено множе- 
ство правок, основанных на отзывах читателей и переосмыслении автором отдель- 
ных идей и формулировок. Благодаря вопросам читателей и дискуссиям на тренин- 
гах удалось уточнить и сгладить спорные моменты, прояснить определения и дать 
пояснения там, где это оказалось необходимым. Идеал недостижим, но хочется ве- 
рить, что в его направлении был сделан большой шаг. 


Эта книга не ставит своей задачей полноценное раскрытие всей предметной 
области со всеми её нюансами, потому не воспринимайте её как учебник или спра- 
вочник — за десятилетия развития тестирование накопило такой объём данных, 
что для его формального представления не хватит и десятка книг. Также прочтения 
лишь этой одной книги вовсе не достаточно, чтобы стать «гуру тестирования». 

Тогда зачем же нужна эта книга!? 

Во-первых, эту книгу стоит прочитать, если вы твёрдо решили заниматься 
тестированием, — она будет полезна как «совсем начинающим», так и имеющим 
некоторый опыт в тестировании. 

Во-вторых, эту книгу можно и нужно использовать как опорный материал во 
время тренингов. Здесь можно и нужно много чёркать, дописывать, отмечать непо- 
нятное, записывать вопросы и т.д. 

В-третьих, эта книга — своего рода «карта», в которой есть ссылки на мно- 
жество внешних источников информации (которые могут оказаться полезными 
даже опытным тестировщикам), а также много примеров с пояснениями. 

Прежде чем мы приступим к изучению основного материала, давайте опре- 
делимся с условными обозначениями: 






Определения и иная важная для запоминания информация. Часто будет | 
тречатьоя рядом CO следующим ИЕН 


_ Дополнительные сведения или отсылка к соответствующим источникам. _ 
‚ Всё то, что полезно знать. При этом оригинальные (англоязычные) опре- 















 Предостережения и частые ошибки. Недостаточно показать, «как пра- 
: вильно», часто большую пользу приносят примеры того, как поступать He 


Задания для самостоятельной проработки. Настоятельно рекомендуется 
выполнять их (даже если вам кажется, что всё очень просто). 
В приложении?” есть комментарии ко многим заданиям, но не спешите | 
да заглядывать — сначала поработайте самостоятельно. 
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В тексте вы встретите два вида сносок в виде чисел: если число не взято в 
фигурные скобки2345 — это обычная сноска, которую нужно искать внизу страницы; 
если число взято в фигурные скобки? — оно представляет собой номер стра- 
ницы, где представлены дополнительные сведения (в электронной версии книги та- 
кая сноска является ссылкой). 


В дополнение к тексту данной книги рекомендуется пройти бесплатный он- 
лайн-курс, содержащий серию видео-уроков, тестов и заданий для самоподготовки. 


Напоследок: ничто в этой книге не является догмой, к любому термину вы 
можете найти альтернативное определение, к любой рекомендации — контраргу- 
менты. И это нормально. Со временем вы станете понимать контекст ситуации и 
применимость (полезность!) той или иной информации. Итак, приступим! 
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Раздел 1: тестирование и тестировщики 


1.1. Что такое тестирование и откуда оно появилось 


В первую очередь дадим определение тестирования ПО, чтобы чётче пони- 
мать, о чём пойдёт речь. 





Тестирование программного обеспечения — процесс анализа про- 
‚ граммного средства и сопутствующей документации с целью выявления 
ефектов и повышения качества про 





/ 










| Ез ‚ В глоссарии ISTQB! нет термина «тестирование ПО», который широко nC- | 
| пользуется в русском языке. Там есть лишь термин «тестирование | 





На протяжении десятилетий развития разработки ПО к вопросам тестирова- 
ния и обеспечения качества подходили очень и очень по-разному. Можно выделить 
несколько основных «эпох тестирования». 


В 50-60-х годах прошлого века процесс тестирования был предельно фор- 
мализован, отделён от процесса непосредственной разработки ПО и «математизи- 
рован». Фактически тестирование представляло собой скорее отладку программ 
(debugging?). Существовала концепция т.н. «исчерпывающего тестирования 
(exhaustive їеѕііпо“)» — проверки всех возможных путей выполнения кода со всеми 
возможными входными данными. Но очень скоро было выяснено, что исчерпываю- 
щее тестирование невозможно, т.к. количество возможных путей и входных данных 
очень велико, а также при таком подходе сложно найти проблемы в документации. 





адание 1.1.а: представьте, что ваша программа по трём введённым це- · 
лым числам определяет, может ли существовать треугольник с такими 
‚длинами сторон. Допустим, что ваша программа выполняется в некоей | 
[ изолированной идеальной среде, и вам всего-то осталось проверить KOP- 
‚ ректность её работы на трёх 8-байтовых знаковых целых числах. Вы nc- | 
[ пользуете автоматизацию, и компьютер может провести 100 миллионов 
‚ проверок в секунду. Сколько займёт проверка всех вариантов? 


| А задумались ли вы, как подготовить для этого теста проверочные данные | 
_(на основе которых можно определить, верно ли сработала программа в | 





В 70-х годах фактически родились две фундаментальные идеи тестирова- 
ния: тестирование сначала рассматривалось как процесс доказательства работо- 
способности программы в некоторых заданных условиях (positive testing5), а затем 
— строго наоборот: как процесс доказательства неработоспособности программы 
в некоторых заданных условиях (negative testing). Это внутреннее противоречие не 
только не исчезло со временем, но и в наши дни многими авторами совершенно 
справедливо отмечается как две взаимодополняющие цели тестирования. 





1 International Software Testing Qualifications Board Glossary. [http://www.istqb.org/downloads/glossary.html] 


2 Testing. The process consisting of all lifecycle activities, both static and dynamic, concerned with planning, preparation and evalu- 
ation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that 
they are fit for purpose and to detect defects. [ISTQB Glossary] 


3 Debugging. The process of finding, analyzing and removing the causes of failures in software. [ISTQB Glossary] 

4 Complete testing, exhaustive testing. A test approach in which the test suite comprises all combinations of input values and 
preconditions. [ISTQB Glossary] 

5 Positive Testing. Testing aimed at showing software works. Also known as «test to pass». [aptest.com] 

6 Negative testing. Testing aimed at showing software does not work. Also known as «test to fail». [aptest.com] 
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Отметим, что «процесс доказательства неработоспособности про- 
граммы» ценится чуть больше, т.к. не позволяет закрывать глаза на обнаруженные 
проблемы. 









‚ Внимание! Скорее всего, именно из этих рассуждений проистекает невер- | 
ное понимание того, что негативные тест-кейсы должны заканчиваться | 
_ возникновением сбоев и отказов в приложении. Нет, это не так. Негатив- ' 
‚ ные тест-кейсы пытаются вызвать сбои и отказы, но корректно работаю- | 
 щее приложение выдерживает это испытание и продолжает работать | 
верно. Также отметим, что ожидаемым результатом негативных тест-кей- ' 
‚ сов является именно корректное поведение приложения, а сами негатив- | 
ные тест-кейсы считаются пройденными успешно, если им не удалось | 
‹ «поломать» приложение. (См. подробности в главе «Чек-листы, TECT- , 
‚кейсы, наборы тест-кейсов»‹!'2)). | 





‚ Много «классики тестирования» можно почерпнуть из книги «Искусство Te- 
‚ стирования программ» Гленфорда Майерса (издания 1979, 2004, 2011 го- | 
дов). Однако большинство критиков отмечает, что эта книга мало подхо- 
дит для начинающих и куда больше ориентирована на программистов, | 
чем на тестировщиков. Что, впрочем, не умаляет её ценности. В ориги- 





ле книга называется «Тһе art of software testing» (Glenford J. Myers). 


Итак, ещё раз самое важное, что тестирование «приобрело» в 70-е годы: 

e тестирование позволяет удостовериться, что программа соответствует тре- 
бованиям; 

e тестирование позволяет определить условия, при которых программа ведёт 
себя некорректно. 


В 80-х годах произошло ключевое изменение места тестирования в разра- 
ботке ПО: вместо одной из финальных стадий создания проекта тестирование 
стало применяться на протяжении всего цикла разработки (software lifecycle”) 
(также см. описание итерационной инкрементальной модели разработки ПО в главе 
«Модели разработки ПО»), что позволило в очень многих случаях не только 
быстро обнаруживать и устранять проблемы, но даже предсказывать и предотвра- 
щать их появление. 

В этот же период времени отмечено бурное развитие и формализация мето- 
дологий тестирования и появление первых элементарных попыток автоматизиро- 
вать тестирование. 


В 90-х годах произошёл переход от тестирования как такового к более все- 
объемлющему процессу, который называется «обеспечение качества (quality assur- 
апсез)», охватывает весь цикл разработки ПО и затрагивает процессы планирова- 
ния, проектирования, создания и выполнения тест-кейсов, поддержку имеющихся 
тест-кейсов и тестовых окружений. Тестирование вышло на качественно новый уро- 
вень, который естественным образом привёл к дальнейшему развитию методоло- 
гий, появлению достаточно мощных инструментов управления процессом тестиро- 
вания и инструментальных средств автоматизации тестирования, уже вполне похо- 
жих на своих нынешних потомков. 





7 Software lifecycle. Тһе period of time that begins when а software product is conceived апа ends when the software is по longer 
available for use. The software lifecycle typically includes a concept phase, requirements phase, design phase, implementation 
phase, test phase, installation and checkout phase, operation and maintenance phase, and sometimes, retirement phase. Note 
these phases may overlap or be performed iteratively. [ISTQB Glossary] 

8 Quality assurance. Part of quality management focused on providing confidence that quality requirements will be fulfilled. [ISTQB 
Glossary] 
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ЕЗ ‚ Хорошим источником дополнительной информации о процессах тестиро- | 


вания является книга Рекса Блэка «Ключевые процессы тестирования» 





В нулевые годы нынешнего века развитие тестирования продолжалось в 
контексте поиска всё новых и новых путей, методологий, техник и подходов к обес- 
печению качества. Серьёзное влияние на понимание тестирования оказало появ- 
ление гибких методологий разработки и таких подходов, как «разработка под управ- 
лением тестированием? (їеѕї-дгімеп development”, TDD)». Автоматизация тестиро- 
вания уже воспринималась как обычная неотъемлемая часть большинства проек- 
тов, а также стали популярны идеи о том, что во главу процесса тестирования сле- 
дует ставить не соответствие программы требованиям, а её способность предоста- 
вить конечному пользователю возможность эффективно решать свои задачи. 


О современном этапе развития тестирования мы будем говорить на протя- 
жении всего остального материала. Если же отметить вкратце основные характе- 
ристики, то получится примерно такой список: гибкие методологии и гибкое тести- 
рование, глубокая интеграция с процессом разработки, широкое использование ав- 
томатизации, колоссальный набор технологий и инструментальных средств, кросс- 
функциональность команды (когда тестировщик и программист во многом могут вы- 
полнять работу друг друга). 





Воистину подробнейшую историю развития тестирования ПО (начиная с 
1822 года, не шутка) можно найти в статье «The History of Software Test- 
іпо»"" на ресурсе «Testing References». Также немалый интерес представ- | 


ляет статья «Тһе Growth of Software Testing»!? 


(David Gelperin, Bill Hetzel 


). 






© адание 1.1.6: если вам не очень хорошо знакомы такие понятия как ТОО, 
BDD, DDT, КОТ, — найдите их описание в Интернете и изучите. Конечно 








9 Да, грамматически корректно будет «разработка под управлением тестирования», но традиционно так сложилось, что 
целый ряд подобных подходов «под управлением...» называют, используя творительный падеж: т.е. «...тестирова- 
нием», «...данными», «...ключевыми словами» ит.д. 

10 Test-driven development. А way о! developing software where the test cases аге developed, апа often automated, before the 
software is developed to run those test cases. [ISTQB Glossary] 

11 «The History of Software Testing» [http://www.testingreferences.com/testinghistory.php] 

12 «The Growth of Software Testing», David Gelperin, Bill Hetzel [https://www.researchgate.net/publica- 
tion/234808293_The_growth_of_software_testing] 
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1.2. Кто такой тестировщик и что он делает 


Если поискать информацию по ключевым фразам из названия этой главы, 
можно найти уйму совершенно противоречивых ответов. И дело здесь в первую 
очередь в том, что авторы большинства «должностных обязанностей» приписы- 
вают всей профессии некий утрированный набор характеристик отдельных её пред- 
ставителей. 

В то же время даже в ЕКСД разделены должности «специалиста по тестиро- 
ванию программного обеспечения» и «тестировщика программного обеспечения». 





‚ Если вам интересно, почитайте документ «Постановление Министерства | 
‚ труда и социальной защиты Республики Беларусь № 148 от 15 декабря 
‚ 2009 г. О внесении изменений и дополнений в выпуск 1 Единого квалифи- | 





Теперь вернёмся к исходному вопросу и посмотрим на него с двух точек зре- 
ния: какова квалификация тестировщика, и где он работает. 


Упрощённо отразим это в таблице 1.2.а. 


Таблица 1.2.а — Типичные виды деятельности тестировщика. 





Небольшие фирмы Большие фирмы 





Низкая квалификация 


Подмастерье, часто предо- 
ставленный сам себе в реше- 
нии задач. 


Рядовой участник проектов, 
одновременно проходящий 
интенсивное повышение ква- 
лификации. 





Высокая квалификация 


Мастер на все руки с богатым, 
но не всегда структурирован- 


Эксперт в одной или несколь- 
ких областях, консультант, ру- 














НЫМ ОПЫТОМ. ководитель направления. 





Поскольку чем выше квалификация специалиста??”, тем шире его выбор 
мест работы (даже в рамках одной крупной фирмы), основное внимание уделим 
именно квалификационным особенностям работы тестировщика. 

В начале карьеры любой специалист (и тестировщик не является исключе- 
нием) является исполнителем и учеником. Достаточно хорошо понимать, что такое 
тест-кейсы, отчёты о дефектах, уметь читать требования, пользоваться парой ин- 
струментальных средств и хорошо уживаться в команде. 

Постепенно тестировщик начинает погружаться во все стадии разработки 
проекта, понимая их всё полнее и полнее, начинает не только активно использо- 
вать, но и разрабатывать проектную документацию, принимать всё более ответ- 
ственные решения. 

Если выразить образно главную цель тестировщика, то она будет звучать 
так: «понимать, что в настоящий момент необходимо проекту, получает ли проект 
это необходимое в должной мере, и, если нет, как изменить ситуацию к лучшему». 
Звучит похоже на цель руководителя проекта, верно? Верно. Начиная с некоторого 
уровня развития, [Т-специалисты, по большому счёту, различаются лишь наборами 
технических навыков и основной областью приложения этих навыков. 


Так какие же технические навыки нужны, чтобы успешно начать работать те- 
стировщиком? Прежде чем приступить к самому перечислению, оговорим особо: 
этот список рассчитан в первую очередь на тех, кто приходит в тестирование из 
нетехнических профессий (хотя часто его же приходится озвучивать и студентам 
технических вузов). 
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0) 


Знание иностранных языков. Да, это нетехнический навык. Но тем не ме- 
нее он идёт под номером «ноль». Можете считать это аксиомой: «нет зна- 
ния английского — нет карьеры в ІТ». Другие иностранные языки тоже 
приветствуются, но английский первичен. 





Задание 1.2.а: если вы сомневаетесь в том, достаточен ли ваш | 
уровень английского, проверьте себя: если вы можете без 
‚ труда читать технические статьи хотя бы в Википедии, MNHM- 





Уверенное владение компьютером на уровне по-настоящему продвину- 
того пользователя и желание постоянно развиваться в этой области. Мо- 
жете ли вы представить себе профессионального повара, который не мо- 
жет пожарить картошку (не «не обязан», а «не умеет в принципе»)? Вы- 
глядит странно? Не менее странно выглядит «|P HNK» (именно так, в Ka- 
вычках), неспособный набрать вменяемо отформатированный текст, ско- 
пировать файл по сети, развернуть виртуальную машину или выполнить 
любое иное повседневное рутинное действие. 

Программирование. Оно на порядки упрощает жизнь любому [Т’шнику — 
и тестировщику в первую очередь. Можно ли тестировать без знания про- 
граммирования? Да, можно. Можно ли это делать по-настоящему хо- 
рошо? Нет. И сейчас самый главный (почти религиозно-философский) 
вопрос: какой язык программирования изучать? С/С++/С#, Java, РНР, Ja- 
уа5сгірї, Python, Ruby и т.д. — начинайте с того, на чём написан ваш npo- 
ект. Если проекта пока ещё нет, начинайте с JavaScript (на текущий MoO- 
мент — самое универсальное решение). 

Базы данных и язык SQL. Здесь от тестировщика тоже не требуется ква- 
лификация на уровне узких специалистов, но минимальные навыки ра- 
боты с наиболее распространёнными СУБД и умение писать простые за- 
просы можно считать обязательными. 

Понимание принципов работы сетей и операционных систем. Хотя бы на 
минимальном уровне, позволяющем провести диагностику проблемы и 
решить её своими силами, если это возможно. 

Понимание принципов работы веб-приложений и мобильных приложе- 
ний. В наши дни почти всё пишется именно в виде таких приложений, и 
понимание соответствующих технологий становится обязательным для 
эффективного тестирования. 


Надеюсь, вы обратили внимание на то, что самого тестирования в списке нет. 
Всё верно, ведь ему посвящена вся эта книга целиком, так что позволим себе не 
копировать её сюда. 


В завершение главы также отметим личностные качества, позволяющие те- 
стировщику быстрее стать отличным специалистом: 


повышенная ответственность и исполнительность; 
хорошие коммуникативные навыки, способность ясно, быстро, чётко вы- 
ражать свои мысли; 

терпение, усидчивость, внимательность к деталям, наблюдательность; 
хорошее абстрактное и аналитическое мышление; 

способность ставить нестандартные эксперименты, склонность к иссле- 
довательской деятельности. 
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Да, сложно найти человека, который бы в равной мере обладал всеми пере- 
численными качествами, но всегда полезно иметь некий ориентир для саморазви- 
тия. 





‚ Очень часто можно услышать вопрос о том, обязательно ли тестировщику | 
иметь техническое высшее образование. Не обязательно. Хотя при его | 
_ наличии на первых этапах карьеры, конечно, легче. Но со временем pas- _ 
ница между теми, у кого такое образование есть, и теми, у кого нет, стано- · 
тся практически незаметной. 
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1.3. Что нужно знать и уметь и чему можно научиться 


В предыдущей главе мы осознанно не обсуждали конкретный перечень не- 
обходимых начинающему тестировщику знаний и умений, т.к. он заслуживает от- 
дельного рассмотрения. 

Показанные ниже данные представляют собой адаптированную выжимку из 
карты компетенций тестировщика. Все навыки здесь условно разделены на три 
группы: 

• Профессиональные — это именно «тестировщицкие», ключевые навыки, от- 
личающие тестировщика от других ІТ-специалистов. 

e Технические — это общие навыки в области |T, которыми тем не менее gon- 
жен обладать и тестировщик. 

e Личностные — в русском языке термин «soft skills» часто переводят как 

«навыки межличностного общения», но исходный термин несколько шире. 








адание 1.3.а: в процессе чтения приведённых здесь перечней компетен 
‚ ций отмечайте непонятные вещи, ищите дополнительную информацию и 
‚ добивайтесь у себя понимания описанного хотя бы на уровне «знаю, о чём 





дёт речь». 





Профессиональные навыки 


Таблица 1.3.а — Профессиональные навыки тестировщика 





Предметная об- 
ласть 


Начальный уро- 
вень 


Уровень младшего или среднего специалиста 





Процессы тестирования и разработки программного обеспечения 





Процесс тестиро- 
вания ПО 





Этому вопросу по- 
священа глава 
«Процессы тестиро- 
вания и разработки 


Глубокое понимание стадий процесса тестирова- 
ния, их взаимосвязи и взаимовлияния, умение 
планировать собственную работу в рамках полу- 
ченного задания в зависимости от стадии тестиро- 
вания 





Общее понимание моделей разработки ПО, их 





Процесс разра- ПО» связи с тестированием, умение расставлять прио- 
ботки ПО ритеты в собственной работе в зависимости от 
стадии развития проекта 
Работа с документацией 





Анализ требова- 
ний 





Тестирование 
требований 


Этому вопросу по- 
священа глава «Те- 
стирование доку- 
ментации и требо- 
ваний» (29) 


Умение определять взаимосвязи и взаимозависи- 
мость между различными уровнями и формами 
представления требований, умение формулиро- 
вать вопросы с целью уточнения неясных момен- 
тов 





Знание свойств хороших требований и наборов 
требований, умение анализировать требования с 
целью выявления их недостатков, умение устра- 
нять недостатки в требованиях, умение применять 
техники повышения качества требований 





Управление тре- 
бованиями 





Бизнес-анализ 








Не требуется 


Общее понимание процессов выявления, доку- 
ментирования, анализа и модификации требова- 
ний 








Общее понимание процессов выявления и доку- 
ментирования различных уровней и форм пред- 
ставления требований 
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Предметная об- 
ласть 


Начальный уро- 
вень 


Уровень младшего или среднего специалиста 





Оценка и планирование 





Создание плана 
тестирования 





Создание страте- 
гии тестирования 





Оценка трудоза- 
трат 


Эти вопросы ча- 
стично затронуты в 
главе «Оценка тру- 
дозатрат, планиро- 


Общее понимание принципов планирования в кон- 
тексте тестирования, умение использовать гото- 
вый тест-план для планирования собственной ра- 
боты 





вание и отчёт- 
ность» !205), но их 
глубокое понимание 


Общее понимание принципов построения страте- 
гии тестирования, умение использовать готовую 
стратегию для планирования собственной работы 





требует отдельного 
длительного изуче- 
ния 


Общее понимание принципов оценки трудозатрат, 
умение оценивать собственные трудозатраты при 
планировании собственной работы 





Работа с тест-кейсами 





Создание чек-ли- 
CTOB 





Создание тест- 
кейсов 


Этому вопросу по- 
священа глава 
«Чек-листы, тест- 
кейсы, наборы тест- 
кейсов»!12} 


Твёрдое умение использовать техники и подходы 
к проектированию тестовых испытаний, умение 
декомпозировать тестируемые объекты и постав- 
ленные задачи, умение создавать чек-листы 





Твёрдое умение оформлять тест-кейсы согласно 

принятым шаблонам, умение анализировать гото- 
вые тест-кейсы, обнаруживать и устранять имею- 
щиеся в них недостатки 





Управление тест- 
кейсами 


Не требуется 


Общее понимание процессов создания, модифи- 
кации и повышения качества тест-кейсов 





Методол 


огии тестирования 





Функциональное и 
доменное тести- 
рование 


Этому вопросу по- 
священа глава «По- 
дробная классифи- 
кация тестирова- 
ния»{66} 


Знание видов тестирования, твёрдое умение ис- 
пользовать техники и подходы к проектированию 
тестовых испытаний, умение создавать чек-листы 
и тест-кейсы, умение создавать отчёты о дефек- 
тах 





Тестирование ин- 
терфейса пользо- 
вателя 





Исследователь- 
ское тестирова- 
ние 





Инте грационное 
тестирование 





Локализационное 
тестирование 





Инсталляционное 
тестирование 





Регрессионное те- 
стирование 


Не требуется 


Умение проводить тестирование интерфейса 
пользователя на основе готовых тестовых сцена- 
риев или в рамках исследовательского тестирова- 
ния 





Общее умение использовать матрицы для быст- 
рого определения сценариев тестирования, об- 
щее умение проводить новые тесты на основе ре- 
зультатов только что выполненных 





Умение проводить интеграционное тестирование 
на основе готовых тестовых сценариев 





Умение проводить локализационное тестирование 
на основе готовых тестовых сценариев 





Умение проводить инсталляционное тестирование 
на основе готовых тестовых сценариев 





Общее понимание принципов организации регрес- 
сионного тестирования, умение проводить регрес- 
сионное тестирование по готовым планам 





Работа с отчётами о дефектах 





Создание отчётов 
о дефектах 


Этому вопросу по- 
священа глава «От- 
чёты о дефек- 
тах»{164} 


Твёрдое знание жизненного цикла отчёта об 
ошибке, твёрдое умение создавать отчёты о де- 
фектах согласно принятым шаблонам, умение 
анализировать готовые отчёты, обнаруживать и 
устранять имеющиеся в них недостатки 





Анализ причин 
возникновения 
ошибки 





Использование 
баг-трекинговых 
систем 








Не требуется 


Базовое умение исследовать приложение с целью 
выявления источника (причины) ошибки, элемен- 
тарное умение формировать рекомендации по 
устранению ошибки 





Умение использовать баг-трекинговые системы на 
всех стадиях жизненного цикла отчётов о дефек- 
тах 
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Что нужно знать и уметь и чему можно научиться 








Предметная об- 
ласть 


Начальный уро- 
вень 


Уровень младшего или среднего специалиста 





Работа с отчётами 


о результатах тестирования 





Создание отчётов 
о результатах те- 
стирования 








Не требуется, но 
частично рассмот- 
рено в главе 
«Оценка трудоза- 
трат, планирование 
и отчётность»{205} 





Умение предоставлять необходимую информацию 
для формирования отчёта о результатах тестиро- 
вания, умение анализировать готовые отчёты о 
результатах тестирования с целью уточнения пла- 
нирования собственной работы 





Технические навыки 


Таблица 1.3.6 — Технические навыки тестировщика. 





Предметная об- 


Начальный уро- 


Уровень младшего или среднего специалиста 














ласть вень 
Операционные системы 
Установка, использование и администрирование, 
Использование на 
. решение проблем, конфигурирование с целью 
Windows уровне уверенного a 
настройки тестового окружения и выполнения 
пользователя $ 
тест-кейсов 
Установка, использование и администрирование, 
| ешение проблем, конфигурирование с целью 
Linux Общее знакомство р ее фигурир ц 
настройки тестового окружения и выполнения 
тест-кейсов 
Мас OS Не требуется Общее знакомство 





Виртуальные ма- 
ШИНЫ 


Использование на 
уровне начинаю- 
щего пользователя 


Установка, использование и администрирование, 
решение проблем, конфигурирование с целью 
настройки тестового окружения и выполнения 
тест-кейсов 





Базы данных 





Реляционная тео- 
рия 





Реляционные 
СУБД 





Язык SQL 


Не требуется 


Общее понимание, умение читать и понимать 
схемы баз данных в общепринятых графических 
нотациях 





Умение устанавливать, настраивать и использо- 
вать для настройки тестового окружения и выпол- 
нения тест-кейсов 





Умение писать и выполнять простые запросы с 
использованием инструментальных средств ра- 
боты с БД/СУБД1"3 





Компьютерные сети 





Сетевые прото- 
колы 





Сетевые утилиты 


Не требуется 


Общее понимание принципов работы стека 
TCP/IP, умение конфигурировать локальные сете- 
вые настройки операционной системы 





Общее понимание и умение использовать ути- 
литы диагностики состояния и неполадок в сети 





Веб-технологии 





Веб-серверы 





Серверы прило- 
жений 





Веб-сервисы 


Не требуется 


Общее понимание принципов работы веб-серве- 
ров, умение устанавливать и настраивать 





Общее понимание принципов работы серверов 
приложений, умение устанавливать и настраивать 





Общее понимание принципов работы веб-серви- 
сов и способов диагностики неполадок в их ра- 
боте 





Языки разметки 








Общее представле- 
ние об HTML и CSS 





Умение использовать HTML и CSS для создания 
простых страниц 








13 «Работа с MySQL, MS SQL Server и Oracle в примерах», Святослав Куликов [http://svyatoslav.biz/database_book/] 
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Что нужно знать и уметь и чему можно научиться 








Предметная об- 
ласть 


Начальный уро- 
вень 


Уровень младшего или среднего специалиста 





Протоколы пере- 
дачи данных 





Языки веб-про- 


Не требуется 


Общее понимание принципов работы протоколов 
прикладного уровня ОЗ|-модели, общее понима- 
ние принципов диагностики возникших неполадок 





Начальные знания хотя бы в одном языке про- 
граммирования, используемом для создания веб- 























граммирования s 
приложений 
Мобильные платформы и технологии 
Android Использование на уровне начинающего пользова- 
теля 
Не требуется 
iOS Использование на уровне начинающего пользова- 


теля 





Личностные навыки 


Таблица 1.3.с — Личностные навыки тестировщика. 





Предметная об- 
ласть 


Начальный уро- 
вень 


Уровень младшего или среднего специалиста 





Коммуникативные навыки 





Деловое исполь- 


Минимальные 


Понимание и строгое следование правилам дело- 
вого общения с использованием e-mail и сервисов 














вание e-mail навыки в 
ВАНИЕ а мгновенных сообщений 
Устное деловое Минимальные Понимание и строгое следование правилам уст- 
общение навыки ного делового общения 
Прохождение со- Начальный опыт прохождения собеседований 
о. b Не требуется рохожд A 
беседований 
Навыки самоорганизации 
Развитые навыки планирования собственного 
Планирование Минимальные 
времени, умение пользоваться соответствую- 
собственного вре- навыки, общие 
щими инструментами, умение оценивать трудоза- 
мени представления 


траты в рамках полученных заданий 





Отчётность о 
своей работе 








Начальные навыки 





Развитые навыки отчётности о своей работе, уме- 
ние пользоваться соответствующими инструмен- 
тами 





Возможно, вы заметили, что в этом перечне навыков нет отдельного списка, 
посвящённого автоматизации тестирования. Он не включён в данную книгу по трём 
причинам: а) он огромен; б) он постоянно меняется; в) эта книга всё же о тестиро- 
вании вообще, хоть в ней и есть краткие сведения об автоматизации (см. раздел 
«Автоматизация тестирования» 2°). Если же сказать в двух словах, то автоматиза- 
тор должен знать всё то же, что и «классический» тестировщик, а также уметь про- 
граммировать на 3—5 языках — хотя бы немного. И всё. Инструменты на начальном 


уровне можно освоить за несколько дней. 
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Мифы и заблуждения о тестировании 





1.4. Мифы и заблуждения о тестировании 


Возможно, здесь вы ожидали прочитать нечто наподобие «Семи бед тести- 
рования» Джеймса Виттакера (см. ниже). Нет, здесь будут «мифы», которые акту- 
альны не для состоявшихся профессионалов, а для новичков и тех, кто ещё только 
собирается обучаться тестированию. 

Текст этой главы составлен в основном по итогам бесед со слушателями тре- 
нингов, а если точнее — по фразам, начинающимся с «а я думал(а), что...» или «а 
правда ли, что...» 








Обязательно почитайте прекрасный цикл статей «Тһе 7 Plagues of Soft- 
аге Тесїїпд»'* (James Whittaker). 





Итак: «А я думал(а), что...» / «А правда ли, что...» 


Не надо разбираться в компьютерах 


Без комментариев. Нет, возможно, существуют некие ничтожно малые доли 
процента деятельности тестировщика, которую можно реализовать «на пальцах». 
Но этой бесконечно малой величиной можно пренебречь. 


Обязательно надо хорошо знать программирование 


Очень больно относить эту мысль к мифам. Хорошо, когда тестировщик 
знает программирование. Ещё лучше, когда он знает его хорошо. Но даже общих 
отдалённых представлений о программировании хватает для начала карьеры. А 
дальше уже — по обстоятельствам. 


В тестировании всё просто 


Если развить аналогию, то и в кулинарии всё просто, если мы говорим о за- 
варивании чая в пакетике. Но как подобным чаем не заканчивается кулинария, так 
и тестирование не заканчивается случаями «ой, тут вот картинка не загрузилась». 
Даже на исключительно практическом уровне задачи тестирования могут быть со- 
поставимы по сложности с задачами проектирования и разработки программ (хм, 
почему ж нет мифа «программирование — это просто», ведь «Hello, world» Hann- 
сать не тяжело). А если мы посмотрим на «надёжность программного обеспечения» 
с научной точки зрения, то перспективы роста сложности вообще ничем не ограни- 
чены. Обязательно ли каждому тестировщику «лезть в эти дебри»? Нет. Но если 
хочется — можно. К тому же это очень интересно. 


В тестировании куча рутины и скуки 


Не больше и не меньше, чем в иных !Т-профессиях. Остальное зависит от 
конкретного тестировщика и того, как он организует свою работу. 





14 «Тһе plague о! гереймепезз», James Whittaker [http://googletesting.blogspot.com/2009/06/by-james.html] 

«Тре Plague of Amnesia», James Whittaker [һіїр://доодіеїеѕііпо.0Іодѕрої.сот/2009/07/ріадие-оѓ-атпеѕіа.һіті] 

«The Plague of Boredom», James Whittaker [http://googletesting.blogspot.com/2009/07/plague-of-boredom.html] 

«The Plague of Homelessness», James Whittaker [http://googletesting.blogspot.com/2009/07/plague-of-homelessness.html] 
«The Plague of Blindness», James Whittaker [http:/googletesting.blogspot.com/2009/07/plague-of-blindness.html] 

«The 7th Plague and Beyond», James Whittaker [http://googletesting.blogspot.com/2009/09/7th-plague-and-beyond.html] 
«The Plague of Entropy», James Whittaker [http://googletesting.blogspot.com/2009/09/plague-of-entropy.html] 
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Мифы и заблуждения о тестировании 





Тестировщика должны всему-всему научить 


Не должны. И уж тем более «всему-всему». Да, если мы говорим о явно обо- 
значенном учебном процессе, то его организаторы (будь то предмет в универси- 
тете, учебный курс в некоем тренинговом центре или отдельный тренинг внутри 
компании) часто берут на себя определённые «педагогические обязательства». Но 
подобная учебная деятельность никогда не заменит саморазвития (хотя и может в 
нужный момент помочь в выборе направления пути). Т-отрасль меняется очень 
интенсивно и непрерывно. Учиться придётся до пенсии. 


В тестировщики идут те, кто не смог стать программистом 


А в скрипачи — те, кто не смог стать пианистом? Я думаю, что некий неболь- 
шой процент «не ставших программистами» в тестировании есть. Но он теряется 
на фоне тех, кто шёл в тестирование изначально и сознательно, а также тех, кто 
пришёл в тестирование из программирования. 


В тестировании сложно построить карьеру 


При должном старании карьера в тестировании оказывается едва ли не са- 
мой динамичной (по сравнению с другими П-направлениями). Тестирование само 
по себе — очень бурно развивающаяся отрасль IT, и здесь всегда можно выбрать 
что-то, что будет вам очень нравиться и хорошо получаться — а в таких условиях 
стать профессионалом и достичь успеха легко. 


Тестировщик «виноват во всём», т.е. с него спрос за все ошибки 


Только если признать, что в болезни пациента виновен термометр, показы- 
вающий высокую температуру. Скорее с тестировщиков будет спрос за те ошибки, 
что были найдены пользователем, т.е. проявились уже на стадии реальной эксплу- 
атации продукта. Но и здесь нет однозначного вывода — за конечный успех про- 
дукта отвечает вся команда, и было бы глупо перекладывать ответственность лишь 
на одну её часть. 


Тестировщики скоро будут не нужны, т.к. всё будет автоматизиро- 
вано 


Как только по улицам забегают терминаторы — да, этот миф станет правдой: 
программы научатся обходиться без людей. Но тогда у нас всех будут другие про- 
блемы. А если кроме шуток, человечество уже сотни лет идёт по пути автоматиза- 
ции, которая накладывает свой отпечаток на всю нашу жизнь и чаще всего позво- 
ляет переложить самую простую и не требующую квалификации работу на машины. 
Но кто же заставляет вас оставаться на уровне исполнителя такой работы? Начи- 
ная с некоторого уровня, тестирование превращается в гармоничное сочетание 
науки и искусства. А многих ли учёных или творцов заменила автоматизация? 


Просьба: возможно, у вас есть какие-то мысли из разряда «А я думал(а), | 
‚ что в тестировании...» / «А правда ли, что в тестировании...». Если так, = 
‚ поделитесь ими, пожалуйста, в анонимном опросе: 
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Раздел 2: основные знания и умения 





Раздел 2: основные знания и умения 
2.1. Процессы тестирования и разработки ПО 


2.1.1. Модели разработки ПО 


Чтобы лучше разобраться в том, как тестирование соотносится с программи- 
рованием и иными видами проектной деятельности, для начала рассмотрим самые 
основы — модели разработки (lifecycle model's) ПО (как часть жизненного цикла 
(software lifecycle) ПО). При этом сразу подчеркнём, что разработка ПО является 
лишь частью жизненного цикла ПО, и здесь мы говорим именно о разработке. 

Материал данной главы относится скорее к дисциплине «управление проек- 
тами», потому здесь рассмотрен крайне сжато: пожалуйста, не воспринимайте его 
как исчерпывающее руководство — здесь едва ли рассмотрена и сотая доля про- 
цента соответствующей предметной области. 





(т) Модель разработки ПО (Software Development Model, SDM) — структура, 
‚ систематизирующая различные виды проектной деятельности, их взаимо- 
действие и последовательность в процессе разработки ПО. Выбор той | 
или иной модели зависит от масштаба и сложности проекта, предметной | 





Выбор модели разработки ПО серьёзно влияет на процесс тестирования, 
определяя выбор стратегии, расписание, необходимые ресурсы и т.д. 

Моделей разработки ПО много, но в общем случае классическими можно 
считать водопадную, \-образную, итерационную инкрементальную, спиральную и 
гибкую. 









Перечень моделей разработки ПО (с кратким описанием), рекомендуе- 
‚ мых к изучению тестировщиками, можно найти в статье «What аге the 





Знать и понимать модели разработки ПО нужно затем, чтобы уже с первых 
дней работы осознавать, что происходит вокруг, что, зачем и почему вы делаете. 
Многие начинающие тестировщики отмечают, что ощущение бессмысленности 
происходящего посещает их, даже если текущие задания интересны. Чем полнее 
вы будете представлять картину происходящего на проекте, тем яснее вам будет 
виден ваш собственный вклад в общее дело и смысл того, чем вы занимаетесь. 

Ещё одна важная вещь, которую следует понимать, состоит в том, что ника- 
кая модель не является догмой или универсальным решением. Нет идеальной мо- 
дели. Есть та, которая хуже или лучше подходит для конкретного проекта, конкрет- 
ной команды, конкретных условий. 








‚ Частая ошибка! Единственное, от чего стоит предостеречь уже сейчас, так | 


| ‚ это от фривольной трактовки модели и перекраивания её «на свой вкус» 
' без кристально чёткого понимания, что и зачем вы делаете. О том, что | 
‚ бывает при нарушении логики модели, прекрасно сказал в своём слайдка- 








15 Lifecycle model. А partitioning of the life оѓ а product ог project into phases. [ISTQB Glossary] 

16 Software lifecycle. The period of time that begins when a software product is conceived and ends when the software is no longer 
available for use. The software lifecycle typically includes a concept phase, requirements phase, design phase, implementation 
phase, test phase, installation and checkout phase, operation and maintenance phase, and sometimes, retirement phase. Note 
these phases may overlap or be performed iteratively. [ISTQB Glossary] 

17 «What аге the Software Development Models?» [http://istqbexamcertification.com/what-are-the-software-development-models/] 

18 «Scrum Tailoring», Максим Дорофеев [http://cartmendum.livejournal.com/10862.html] 
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Водопадная модель (waterfall тоде!‘) сейчас представляет скорее истори- 
ческий интерес, т.к. в современных проектах практически неприменима. Она пред- 
полагает однократное выполнение каждой из фаз проекта, которые, в свою оче- 
редь, строго следуют друг за другом (рисунок 2.1.а). Очень упрощенно можно ска- 
зать, что в рамках этой модели в любой момент времени команде «видна» лишь 
предыдущая и следующая фаза. В реальной же разработке ПО приходится «видеть 
весь проект целиком» и возвращаться к предыдущим фазам, чтобы исправить 
недоработки или что-то уточнить. 


Общее 
планирование № 
Пользовательские 
требования № 
Системные 
требования № 
Техническая 
архитектура y 
Детализированный 
дизайн № 
| Разработка и 
| отладка y 
| 
| 
| Интеграция и 
модульные тесты № 
| 
| 
| Инсталляционное 
| тестирование y 
| 
| 
О-Б сыш шшш Системное 
| тестирование y 


Тестирование в явном виде 


г 

1 

г | 

| | появляется лишь с середины | Приёмочное 

| | развития проекта, достигая | тестирование y 
I1 

1 

= 


своего максимума B самом конце. 


а а а LLL LLL | Итоговая 
| отчётность 


Рисунок 2.1.а — Водопадная модель разработки ПО 


К недостаткам водопадной модели принято относить тот факт, что участие 
пользователей ПО в ней либо не предусмотрено вообще, либо предусмотрено 
лишь косвенно на стадии однократного сбора требований. С точки зрения же тести- 
рования эта модель плоха тем, что тестирование в явном виде появляется здесь 
лишь с середины развития проекта, достигая своего максимума в самом конце. 





19 In a waterfall model, each phase must Бе completed fully before the next phase сап begin. This type of model is basically used 
for the project which is small and there are no uncertain requirements. At the end of each phase, a review takes place to deter- 
mine if the project is on the right path and whether or not to continue ог discard the project. [http://istqbexamcertifica- 
tion.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/] 
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Тем не менее водопадная модель часто интуитивно применяется при выпол- 
нении относительно простых задач, а её недостатки послужили прекрасным отправ- 
ным пунктом для создания новых моделей. Также эта модель в несколько усовер- 
шенствованном виде используется на крупных проектах, в которых требования 
очень стабильны и могут быть хорошо сформулированы в начале проекта (аэро- 
космическая область, медицинское ПО и т.д.). 





Относительно краткое и притом хорошее описание водопадной модели | 
‚можно найти в статье «What is Waterfall model advantages, disadvantages 
апа when to use it? »20, 


| Великолепное описание истории развития и заката водопадной модели 
‚ было создано Максимом Дорофеевым в виде слайдкаста «Тһе Rise Апа 





Ү-образная модель (\-тоде/22) является логическим развитием водопад- 
ной. Можно заметить (рисунок 2.1.5), что в общем случае как водопадная, так и V- 
образная модели жизненного цикла ПО могут содержать один и тот же набор ста- 
дий, но принципиальное отличие заключается в том, как эта информация исполь- 
зуется в процессе реализации проекта. 

Очень упрощённо можно сказать, что при использовании у-образной модели 
на каждой стадии «на спуске» нужно думать о том, что и как будет происходить на 
соответствующей стадии «на подъёме». Тестирование здесь появляется уже на са- 
мых ранних стадиях развития проекта, что позволяет минимизировать риски, а 
также обнаружить и устранить множество потенциальных проблем до того, как они 
станут проблемами реальными. 


о и 1 
Общее РЕА МЕР ЕЕ > Итоговая 
планирование | Тестирование отчётность 
y i появляется C a 
Пользовательские о ‚ самого начала Е => Приёмочное 
требования проекта. | тестирование 
Ө ЖИ a 
Системные Системное 
Е Ш с НИИ га 
требования y 4 тестирование 
Техническая ой [> Инсталляционное 
архитектура D 4 тестирование 
Детализированный а Интеграция и 
дизайн D 4 модульные тесты 
Разработка и отладка 


Рисунок 2.1.6 — \/-образная модель разработки ПО 





20 «What is Waterfall model advantages, disadvantages апа when to use it?» [http://istqbexamcertification.com/what-is-waterfall- 
model-advantages-disadvantages-and-when-to-use-it/] 

21 ЖЖ Максима Дорофеева. [http://cartmendum.livejournal.com/44064.html] 

22 Y-model. А framework to describe the software development lifecycle activities from requirements specification to maintenance. 
The V-model illustrates how testing activities can be integrated into each phase of the software development lifecycle. [ISTQB 
Glossary] 
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ЕЗ Краткое описание \-образной модели можно найти в статье «What is V- 


 по4е! advantages, disadvantages апа when to use #?»2з. Пояснение по nc- | 
пользованию у-образной модели в тестировании можно найти в статье | 





Итерационная инкрементальная модель (iterative model, incremental 
тоде!) является фундаментальной основой современного подхода к разработке 
ПО. Как следует из названия модели, ей свойственна определённая двойствен- 
ность (а І5ТОВ-глоссарий даже не приводит единого определения, разбивая его на 
отдельные части): 

• с точки зрения жизненного цикла модель является итерационной, т.к. под- 
разумевает многократное повторение одних и тех же стадий; 

• с точки зрения развития продукта (приращения его полезных функций) мо- 
дель является инкрементальной. 


Ключевой особенностью данной модели является разбиение проекта на от- 
носительно небольшие промежутки (итерации), каждый из которых в общем случае 
может включать в себя все классические стадии, присущие водопадной и \- 
образной моделям (рисунок 2.1.с). Итогом итерации является приращение (инкре- 
мент) функциональности продукта, выраженное в промежуточном билде (build?). 


ЕЙ Архитектура и Разработка и 
Еа дизайн отладка 











Обшее 


планирование / Планирование + Интеграция и ` 
Н требования модульные тесты \ 
| | | | 








7 Җ Отчётность Установка билда 
тоговая ` 
отчётность М о 4 


S Оценка 
т ре т <1— Тестирование 


Рисунок 2.1.с — Итерационная инкрементальная модель разработки ПО 





23 «What is V-model advantages, disadvantages and when to use it?» [http://istqbexamcertification.com/what-is-v-model-advantages- 
disadvantages-and-when-to-use-it/] 
24 «Using V Models for Testing», Donald Firesmith [https://insights.sei.cmu.edu/sei_blog/2013/11/using-v-models-for-testing.html] 


25 Iterative development model. A development lifecycle where a project is broken into a usually large number of iterations. An 
iteration is a complete development loop resulting in a release (internal or external) of an executable product, a subset of the 
final product under development, which grows from iteration to iteration to become the final product. [ISTQB Glossary] 

26 Incremental development model. A development lifecycle where a project is broken into a series of increments, each of which 
delivers a portion of the functionality in the overall project requirements. The requirements are prioritized and delivered in priority 
order in the appropriate increment. In some (but not all) versions of this lifecycle model, each subproject follows a 'mini М-тоае!' 
with its own design, coding and testing phases. [ISTQB Glossary] 

27 Build. A development activity whereby a complete system is compiled and linked, so that a consistent system is available including 
all latest changes. [На основе определения термина «daily build» из ISTQB Glossary] 
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Длина итераций может меняться в зависимости от множества факторов, од- 
нако сам принцип многократного повторения позволяет гарантировать, что и тести- 
рование, и демонстрация продукта конечному заказчику (с получением обратной 
связи) будет активно применяться с самого начала и на протяжении всего времени 
разработки проекта. 

Во многих случаях допускается распараллеливание отдельных стадий 
внутри итерации и активная доработка с целью устранения недостатков, обнару- 
женных на любой из (предыдущих) стадий. 

Итерационная инкрементальная модель очень хорошо зарекомендовала 
себя на объёмных и сложных проектах, выполняемых большими командами на про- 
тяжении длительных сроков. Однако к основным недостаткам этой модели часто 
относят высокие накладные расходы, вызванные высокой «бюрократизированно- 
стью» и общей громоздкостью модели. 










тносительно краткие и очень хорошие описания итерационной инкре 
_ ментальной модели можно найти в статьях «What is Iterative model ad- 





vantages, disadvantages апа when to use ї?» и «What is Incremental тоае! | 





Спиральная модель (spiral model) представляет собой частный случай 
итерационной инкрементальной модели, в котором особое внимание уделяется 
управлению рисками, в особенности влияющими на организацию процесса разра- 
ботки проекта и контрольные точки. 

Схематично суть спиральной модели представлена на рисунке 2.1.4. Обра- 
тите внимание на то, что здесь явно выделены четыре ключевые фазы: 

e проработка целей, альтернатив и ограничений; 
e анализ рисков и прототипирование; 

e разработка (промежуточной версии) продукта; 
e планирование следующего цикла. 


С точки зрения тестирования и управления качеством повышенное внимание 
рискам является ощутимым преимуществом при использовании спиральной мо- 
дели для разработки концептуальных проектов, в которых требования естествен- 
ным образом являются сложными и нестабильными (могут многократно меняться 
по ходу выполнения проекта). 

Автор модели Barry Boehm в своих публикациях?" 32 подробно раскрывает эти 
вопросы и приводит множество рассуждений и рекомендаций о том, как применять 
спиральную модель с максимальным эффектом. 









тносительно краткие и очень хорошие описания спиральной модели · 
можно найти в статьях «What is Spiral model - advantages, disadvantages о 





28 «What is Iterative model advantages, disadvantages апа when to use it?» [http://istqbexamcertification.com/what-is-iterative- 
model-advantages-disadvantages-and-when-to-use-it/] 

29 «What is Incremental model advantages, disadvantages and when to use it?» [http://istqbexamcertification.com/what-is-incremen- 
tal-model-advantages-disadvantages-and-when-to-use-it/] 

30 Spiral model. A software lifecycle model which supposes incremental development, using the waterfall model for each step, with 
the aim of managing risk. In the spiral model, developers define and implement features in order of decreasing priority. 
[https://www.geeksforgeeks.org/software-engineering-spiral-model/] 

31 «A Spiral Model of Software Development and Enhancement», Barry Boehm [http://www-scf.usc.edu/~csci201/lectures/Lec- 
ture11/boehm1988.pdf] 

32 «Spiral Development: Experience, Principles, and Refinements», Barry Boehm. [http://www.sei.cmu.edu/reports/00sr008.paf] 

33 «What is Spiral model- advantages, disadvantages and when to use it?» [http://istqbexamcertification.com/what-is-spiral-model- 
advantages-disadvantages-and-when-to-use-it/] 

34 «Spiral Model» [https://searchsoftwarequality.techtarget.com/definition/spiral-model] 
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Рисунок 2.1.4 — Спиральная модель разработки ПО 


Гибкая модель (agile model) представляет собой совокупность различных 
подходов к разработке ПО и базируется на т.н. «адііе-манифесте»з: 
Люди и взаимодействие важнее процессов и инструментов. 
Работающий продукт важнее исчерпывающей документации. 
Сотрудничество с заказчиком важнее согласования условий контракта. 
Готовность к изменениям важнее следования первоначальному плану. 





‚ Данная тема является настолько большой, что ссылок на статьи недоста- | 
‚ точно, а потому стоит почитать эти книги: | 
‚ ® «Agile Testing» (Lisa Crispin, Janet Gregory). 








35 Agile software development. A group of software development methodologies based on EITP iterative incremental development, 
where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. [ISTQB Glos- 
sary] 

36 «Agile-manngecT» [http://agilemanifesto.org/iso/ru/manifesto.html] 
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Как несложно догадаться, положенные в основу гибкой модели подходы яв- 


ляются логическим развитием и продолжением всего того, что было за десятилетия 
создано и опробовано в водопадной, \-образной, итерационной инкрементальной, 
спиральной и иных моделях. Причём здесь впервые был достигнут ощутимый ре- 
зультат в снижении бюрократической составляющей и максимальной адаптации 
процесса разработки ПО к мгновенным изменениям рынка и требований заказчика. 
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Рисунок 2.1.е — Суть гибкой модели разработки ПО 


Очень упрощённо (почти на грани допустимого) можно сказать, что гибкая 


модель представляет собой облегчённую с точки зрения документации смесь ите- 
рационной инкрементальной и спиральной моделей (рисунки 2.1.е, 2.1.1); при этом 


следует помнить об «адііе-манифесте» и всех вытекающих из него преимуществах 


и недостатках. 
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Рисунок 2.1.1 — Итерационный подход в рамках гибкой модели n scrum 


Главным недостатком гибкой модели считается сложность её применения к 
крупным проектам, а также частое ошибочное внедрение её подходов, вызванное 
недопониманием фундаментальных принципов модели. 

Тем не менее можно утверждать, что всё больше и больше проектов начи- 
нают использовать гибкую модель разработки. 


‚ Очень подробное и элегантное изложение принципов применения гибкой | 
‚модели разработки ПО можно найти в статье «The Agile System Develop- 





Вкратце можно выразить суть моделей разработки ПО таблицей 2.1.а. 


Таблица 2.1.а — Сравнение моделей разработки ПО 

















есть чёткий прове- 
ряемый результат. 
Внимание тестиро- 
ванию уделяется с 
первой же стадии. 
Хорошо работает 
для проектов со 
стабильными тре- 
бованиями. 





кость и адаптируе- 
мость. 

e Отсутствует раннее 
прототипирование. 

• Сложность устра- 
нения проблем, 
пропущенных на 
ранних стадиях 
развития проекта. 





Модель Преимущества Недостатки Тестирование 
Водопадная У каждой стадии • Полная неспособ- • С середины про- 
есть чёткий прове- ность адаптировать екта. 
ряемый результат. проект к измене- 
В каждый момент ниям в требова- 
времени команда ниях. 
выполняет один • Крайне позднее со- 
вид работы. здание работаю- 
Хорошо работает щего продукта. 
для небольших за- 
дач. 
Ү-образная У каждой стадии • Недостаточная гиб- |» На переходах 


между стадиями. 








37 «Тһе Agile System Development Life Cycle» [http://www.ambysoft.com/essays/agileLifecycle.html] 
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Модели разработки ПО 


























Итерационная инкре- Достаточно раннее Недостаточная гиб- |» В определённые 

ментальная прототипирование. кость внутри итера- моменты итераций. 
Простота управле- ций. • Повторное тестиро- 
ния итерациями. Сложность устра- вание (после дора- 
Декомпозиция про- нения проблем, ботки) уже прове- 
екта на управляе- пропущенных на ренного ранее. 
мые итерации. ранних стадиях 

развития проекта. 

Спиральная Глубокий анализ Высокие накладные 
рисков. расходы. 

Подходит для круп- Сложность приме- 

ных проектов. нения для неболь- 

Достаточно раннее ших проектов. 

прототипирование. Высокая зависи- 
мость успеха от ка- 
чества анализа 
рисков. 

Гибкая Максимальное во- Сложность реали- • В определённые 
влечение заказ- зации для больших моменты итераций 
чика. проектов. и в любой необхо- 
Много работы с Сложность постро- димый момент. 
требованиями. ения стабильных 
Тесная интеграция процессов. 
тестирования и 
разработки. 

Минимизация доку- 
ментации. 











Ещё два кратких и информативных сравнения моделей жизненного цикла | 
ПО можно найти в статьях «Project Lifecycle Models: Ном They Differ апа 
-When їо Use Them» и «Блок-схема выбора оптимальной методологии | 


разработки ПО». А общий обзор всех моделей в контексте тестирования | 








тот вопрос сейчас, а ответ запишите. 





‚ Задание 2.1.а: представьте, что на собеседовании вас попросили назвать ' 
‚ основные модели разработки ПО, перечислить их преимущества и Hego- 
статки с точки зрения тестирования. Не ждите собеседования, ответьте на | 


38 «Project Lifecycle Models: How They Differ апа When to Use Them» [http://www.business-esolutions.com/isIm.htm] 
39 «Блок-схема выбора оптимальной методологии разработки ПО» [http://megamozg.ru/post/23022/] 
40 «What аге the Software Development Models?» [http://istqbexamcertification.com/what-are-the-software-development-models/] 
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2.1.2. Жизненный цикл тестирования 


Следуя общей логике итеративности, превалирующей во всех современных 
моделях разработки ПО, жизненный цикл тестирования также выражается замкну- 
той последовательностью действий (рисунок 2.1.0). 

Важно понимать, что длина такой итерации (и, соответственно, степень по- 
дробности каждой стадии) может варьироваться в широчайшем диапазоне — от 
единиц часов до десятков месяцев. Как правило, если речь идёт о длительном про- 
межутке времени, он разбивается на множество относительно коротких итераций, 
но сам при этом «тяготеет» ктой или иной стадии в каждый момент времени (напри- 
мер, в начале проекта больше планирования, в конце — больше отчётности). 

Также ещё раз подчеркнём, что приведённая схема — не догма, и вы легко 
можете найти альтернативы (например, здесь“! и здесь), но общая суть и ключе- 
вые принципы остаются неизменными. Их и рассмотрим. 


Общее планирование и 
анализ требований 





Уточнение критериев 


Отчётность А 
приёмки 


Анализ результатов Уточнение стратегии 
тестирования тестирования 


Фиксация найденных 
дефектов 


Разработка тест-кейсов 


Выполнение тест- 
кейсов 


Рисунок 2.1.9 — Жизненный цикл тестирования 


Стадия 1 (общее планирование и анализ требований) объективно необхо- 
дима как минимум для того, чтобы иметь ответ на такие вопросы, как: что нам пред- 
стоит тестировать; как много будет работы; какие есть сложности; всё ли необхо- 
димое у нас есть и т.п. Как правило, получить ответы на эти вопросы невозможно 
без анализа требований, т.к. именно требования являются первичным источником 
ответов. 

Стадия 2 (уточнение критериев приёмки) позволяет сформулировать или 
уточнить метрики и признаки возможности или необходимости начала тестирова- 
ния (entry сщепа“з), приостановки (suspension сщепа““) и возобновления (resumption 





41 «Software Testing Life Cycle» [http://softwaretestingfundamentals.com/software-testing-life-cycle/] 

42 «Software Testing Life Cycle» [http://www.softwaretestingmentor.com/software-testing-life-cycle/] 

43 Entry criteria. The set of generic and specific conditions for permitting a process to go forward with a defined task, e.g. test phase. 
The purpose of entry criteria is to prevent a task from starting which would entail more (wasted) effort compared to the effort 
needed to remove the failed entry criteria. [ISTQB Glossary] 


44 Suspension criteria. The criteria used to (temporarily) stop all or a portion of the testing activities on the test items. [ISTQB 
Glossary] 
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сШепа“з) тестирования, завершения или прекращения тестирования (exit спїїепа“). 

Стадия 3 (уточнение стратегии тестирования) представляет собой ещё одно 
обращение к планированию, но уже на локальном уровне: рассматриваются и уточ- 
няются те части стратегии тестирования (test strategy“), которые актуальны для TE- 
кущей итерации. 

Стадия 4 (разработка тест-кейсов) посвящена разработке, пересмотру, уточ- 
нению, доработке, переработке и прочим действиям с тест-кейсами, наборами тест- 
кейсов, тестовыми сценариями и иными артефактами, которые будут использо- 
ваться при непосредственном выполнении тестирования. 

Стадия 5 (выполнение тест-кейсов) и стадия 6 (фиксация найденных дефек- 
тов) тесно связаны между собой и фактически выполняются параллельно: дефекты 
фиксируются сразу по факту их обнаружения в процессе выполнения тест-кейсов. 
Однако зачастую после выполнения всех тест-кейсов и написания всех отчётов о 
найденных дефектах проводится явно выделенная стадия уточнения, на которой 
все отчёты о дефектах рассматриваются повторно с целью формирования единого 
понимания проблемы и уточнения таких характеристик дефекта, как важность и 
срочность. 

Стадия 7 (анализ результатов тестирования) и стадия 8 (отчётность) также 
тесно связаны между собой и выполняются практически параллельно. Формулиру- 
емые на стадии анализа результатов выводы напрямую зависят от плана тестиро- 
вания, критериев приёмки и уточнённой стратегии, полученных на стадиях 1, 2 и З. 
Полученные выводы оформляются на стадии 8 и служат основой для стадий 1, 2 и 
3 следующей итерации тестирования. Таким образом, цикл замыкается. 


В жизненном цикле тестирования пять из восьми стадий так или иначе свя- 
заны с управлением проектами, рассмотрение которого не входит в наши планы, а 
потому обо всём, что касается планирования и отчётности, мы кратко поговорим в 
главе «Оценка трудозатрат, планирование и отчётность» 20. А сейчас мы перехо- 
дим к ключевым навыкам и основным видам деятельности тестировщиков и начнём 
с работы с документацией. 





45 Resumption criteria. Тһе criteria used to restart all ог а portion of the testing activities that меге suspended previously. [ISTQB 
Glossary] 

46 Eyit criteria. The set of generic and specific conditions, agreed upon with the stakeholders for permitting a process to be officially 
completed. The purpose of exit criteria is to prevent a task from being considered completed when there are still outstanding 
parts of the task which have not been finished. Exit criteria are used to report against and to plan when to stop testing. [ISTQB 
Glossary] 

47 Test strategy. A high-level description of the test levels to be performed and the testing within those levels for an organization or 
program (one or more projects). [ISTQB Glossary] 
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2.2. Тестирование документации и требований 


2.2.1. Что такое «требование» 


Как мы только что рассмотрели в главе, посвящённой жизненному циклу те- 
стирования, всё так или иначе начинается с документации и требований. 






Требование (requirement!) — описание того, какие функции и с соблюде- | 
‚ нием каких условий должно выполнять приложение в процессе решения 
полезной для пользователя задачи. 






ебольшое «историческое отступление»: если поискать определения тре- 
‚ бований в литературе 10-20-30-летней давности, то можно заметить, что | 
' изначально о пользователях, их задачах и полезных для них свойствах | 
‚приложения в определении требования не было сказано. Пользователь | 
выступал некоей абстрактной фигурой, не имеющей отношения к прило- | 
' жению. В настоящее время такой подход недопустим, т.к. он не только | 
‚ приводит к коммерческому провалу продукта на рынке, но и многократно | 
‹ повышает затраты на разработку и тестирование 





орошим кратким предисловием ко всему тому, что будет рассмотрено в 


данной главе, можно считать небольшую статью «What is documentation о 





48 Requirement. А condition ог capability needed by а user іо solve а problem ог achieve ап objective that must be те! ог possessed 
by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. [ISTQB 
glossary] 

49 «What is documentation testing in software testing». [http://istqbexamcertification.com/what-is-documentation-testing/] 
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2.2.2. Важность требований 


Требования являются отправной точкой для определения того, что проектная 
команда будет проектировать, реализовывать и тестировать. Элементарная логика 
говорит нам, что если в требованиях что-то «не то», то и реализовано будет «не 
то», т.е. колоссальная работа множества людей будет выполнена впустую. Эту 
мысль иллюстрирует рисунок 2.2.а. 

Брайан Хэнкс, описывая важность требований, подчёркивает, что они: 

• Позволяют понять, что и с соблюдением каких условий система должна де- 


лать. 

• Предоставляют возможность оценить масштаб изменений и управлять изме- 
нениями. 

• Являются основой для формирования плана проекта (в том числе плана те- 
стирования). 


• Помогают предотвращать или разрешать конфликтные ситуации. 
e Упрощают расстановку приоритетов в наборе задач. 
• Позволяют объективно оценить степень прогресса в разработке проекта. 


Вне зависимости от того, какая модель разработки ПО используется на про- 
екте, чем позже будет обнаружена проблема, тем сложнее и дороже будет её ре- 
шение. А в самом начале («водопада», «спуска по букве у», «итерации», «витка 
спирали») идёт планирование и работа с требованиями. 

Если проблема в требованиях будет выяснена на этой стадии, её решение 
может свестись к исправлению пары слов в тексте, в то время как недоработка, 
вызванная пропущенной проблемой в требованиях и обнаруженная на стадии экс- 
плуатации, может даже полностью уничтожить проект. 


Стоимость 
исправления 
А 
ошибки 


1000 


500 


20 





Время, 
затраченное 
на проект 

> 














Общее 
планирование 








Системные 
требования 








Детализированный 
дизайн 








Интеграция и 
модульные тесты 








Системное 
тестирование 








Итоговая 
отчётность 








Пользовательские 
требования 











Техническая 
архитектура 








Разработка и 
отладка 








Инсталляци онное 
тестирование 








Приёмочное 
тестирование 








Эксплуатация 








Рисунок 2.2.а — Стоимость исправления ошибки в зависимости от момента её об- 
наружения 


Если графики вас не убеждают, попробуем проиллюстрировать ту же мысль 
на простом примере. Допустим, вы с друзьями составляете список покупок перед 
поездкой в гипермаркет. Вы поедете покупать, а друзья ждут вас дома. Сколько 





50 «Requirements іп the Real World», Brian F. Hanks, February 28, 2002. 
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«стоит» дописать, вычеркнуть или изменить пару пунктов, пока вы только-только 
составляете список? Нисколько. Если мысль о несовершенстве списка настигла вас 
по пути в гипермаркет, уже придётся звонить (дёшево, но не бесплатно). Если вы 
поняли, что в списке «что-то не то» в очереди на кассу, придётся возвращаться в 
торговый зал и тратить время. Если проблема выяснилась по пути домой или даже 
дома, придётся вернуться в гипермаркет. И, наконец, клинический случай: в списке 
изначально было что-то уж совсем неправильное (например, «100 кг конфет — и 
всё»), поездка совершена, все деньги потрачены, конфеты привезены и только тут 
выясняется, что «ну мы же пошутили». 





адание 2.2.а: представьте, что ваш с друзьями бюджет ограничен, и в 


| Е списке требований появляются приоритеты (что-то купить надо обяза- 
| ‚ тельно, что-то, если останутся деньги, и т.п.). Как это повлияет на риски, | 
связанные с ошибками в списке? 





Ещё одним аргументом в пользу тестирования требований является то, что, 
по разным оценкам, в них зарождается от ?% до 34 всех проблем с программным 
обеспечением. В итоге есть риск, что получится так, как показано на рисунке 2.2.5. 

Поскольку мы постоянно говорим «документация и требования», а не просто 
«требования», то стоит рассмотреть перечень документации, которая должна под- 
вергаться тестированию в процессе разработки ПО (хотя далее мы будем концен- 
трироваться именно на требованиях). 





Так клиент 
объяснил, чего он 
хочет 


Так проект был 
задокументирован 


Так клиента понял 
менеджер проекта 


Так проект был 
сдан в 
эксплуатацию 


Так аналитик 
описал проект 


В такую сумму 
проект обошёлся 
заказчику 





Так программист 
реализовал проект 


Так работала 
техническая 
поддержка 





Так проект был 
прорекламирован 
консультантами 


Что на самом деле 


было нужно 
клиенту 


Рисунок 2.2.6 — Типичный проект с плохими требованиями 


В общем случае документацию можно разделить на два больших вида в за- 
висимости от времени и места её использования (здесь будет очень много сносок 
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с определениями, т.к. по видам документации очень часто возникает множество во- 
просов и потому придётся рассмотреть некоторые моменты подробнее). 


e Продуктная документация (product documentation, development documenta- 
іїопѕ') используется проектной командой во время разработки и поддержки 
продукта. Она включает: 

о План проекта (project management р!ап?2) и в том числе тестовый план 
(test р!апзз). 

о Требования к программному продукту (product requirements document, 
РАО) и функциональные спецификации (functional зресйсаНопз:5 doc- 
итепї, Е$056; software requirements specification, 58557). 

о Архитектуру и дизайн (architecture апа аез!дп:®). 

Тест-кейсы и наборы тест-кейсов (test саѕеѕ, test suites®?). 

о Технические спецификации (technical specifications®), такие как схемы 
баз данных, описания алгоритмов, интерфейсов и т.д. 


О 


e Проектная документация (project documentations?) включает в себя как npo- 
дуктную документацию, так и некоторые дополнительные виды документа- 
ции и используется не только на стадии разработки, но и на более ранних и 
поздних стадиях (например, на стадии внедрения и эксплуатации). Она вклю- 
чает: 





51 Development documentation. Development documentation comprises those documents that propose, specify, plan, review, test, 
and implement the products of development teams in the software industry. Development documents include proposals, user or 
customer requirements description, test and review reports (suggesting product improvements), and self-reflective documents 
written by team members, analyzing the process from their perspective. [«Documentation for Software and IS Development», 
Thomas T. Barker, «Encyclopedia of Information Systems» (Elsevier Press, 2002, pp. 684-694.)] 


52 Project management plan. A formal, approved document that defines how the project is executed, monitored and controlled. It 
may be summary or detailed and may be composed of one of more subsidiary management plans and other planning documents. 
[PMBOK, 3" edition] 

53 Test plan. A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst 
others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test 
environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks 
requiring contingency planning. It is a record of the test planning process. [ISTQB Glossary] 

54 Product requirements document, PRD. The PRD describes the product your company will build. It drives the efforts of the entire 
product team and the company’s sales, marketing and customer support efforts. The purpose of the product requirements doc- 
ument (PRD) or product spec is to clearly and unambiguously articulate the ргодисЁ$ purpose, features, functionality, and be- 
havior. The product team will use this specification to actually build and test the product, so it needs to be complete enough to 
provide them the information they need to do their jobs. [«How to write a good PRD», Martin Cagan] 

55 Specification. A document that specifies, ideally in a complete, precise and verifiable manner, the requirements, design, behavior, 
or other characteristics of a component or system, and, often, the procedures for determining whether these provisions have 
been satisfied. [ISTQB Glossary] 

56 Functional specifications document, FSD. Cm. «Software requirements specification, SRS». 


57 Software requirements specification, SRS. SRS describes as fully as necessary the expected behavior of the software system. 
The SRS is used in development, testing, quality assurance, project management, and related project functions. People call this 
deliverable by many different names, including business requirements document, functional spec, requirements document, and 
others. [«Software Requirements (33 edition)», Karl Wiegers апа Joy Beatty] 


58 Architecture. Design. A software architecture for a system is the structure or structures of the system, which comprise elements, 
their externally-visible behavior, and the relationships among them. ... Architecture is design, but not all design is architecture. 
That is, there are many design decisions that are left unbound by the architecture, and are happily left to the discretion and good 
judgment of downstream designers and implementers. The architecture establishes constraints on downstream activities, and 
those activities must produce artifacts (finer-grained designs and code) that are compliant with the architecture, but architecture 
does not define an implementation. [«Documenting Software Architectures», Paul Clements и др.] 


59 Test case. A set of input values, execution preconditions, expected results and execution postconditions, developed for a particular 
objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement. 
[ISTQB Glossary] 

60 Test suite. A set of several test cases for a component or system under test, where the post condition of one test is often used as 
the precondition for the next one. [ISTQB Glossary] 

61 Technical specifications. Scripts, source code, data definition language, etc. [РМВОК, 3" edition] Также cm. «Specification». 

62 Project documentation. Other expectations and deliverables that are not a part of the software the team implements, but that are 
necessary to the successful completion of the project as a whole. [«Software Requirements (3' edition)», Karl Wiegers and Joy 
Beatty] 
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о Пользовательскую и сопроводительную документацию (иѕег апа ас- 
сотрапуіпо доситепїаіопвз), такую как встроенная помощь, руковод- 
ство по установке и использованию, лицензионные соглашения и т.д. 

о Маркетинговую документацию (market requirements document, МАО“), 
которую представители разработчика или заказчика используют как на 
начальных этапах (для уточнения сути и концепции проекта), так и на 
финальных этапах развития проекта (для продвижения продукта на 
рынке). 


В некоторых классификациях часть документов из продуктной документации 
может быть перечислена в проектной документации — это совершенно нормально, 
т.к. понятие проектной документации по определению является более широким. 
Поскольку с этой классификацией связано очень много вопросов и непонимания, 
отразим суть ещё раз — графически (см. рисунок 2.2.с) — и напомним, что мы до- 
говорились классифицировать документацию по признаку того, где (для чего) она 
является наиболее востребованной. 





Проектная документация 










Продуктная 
документация 





Рисунок 2.2.с — Соотношение понятий «продуктная документация» и «проектная 
документация» 


Степень важности и глубина тестирования того или иного вида документации 
и даже отдельного документа определяется большим количеством факторов, но 
неизменным остаётся общий принцип: всё, что мы создаём в процессе разработки 
проекта (даже рисунки маркером на доске, даже письма, даже переписку в скайпе), 
можно считать документацией и так или иначе подвергать тестированию (напри- 
мер, вычитывание письма перед отправкой — это тоже своего рода тестирование 
документации). 





63 User documentation. User documentation refers to the documentation for а product ог service provided їо the епа users. Тһе 
user documentation is designed to assist end users to use the product or service. This is often referred to as user assistance. 
The user documentation is а part of the overall product delivered to the customer. [На основе статей doc-department.com] 

64 Market requirements document, MRD. An MRD goes into details about the target market segments and the issues that pertain 
to commercial success. [«Software Requirements (3" edition)», Karl Wiegers and Joy Beatty] 





Тестирование программного обеспечения. Базовый курс. © ЕРАМ Systems, 2015-2021 Стр: 33/298 


Источники и пути выявления требований 





2.2.3. Источники и пути выявления требований 


Требования начинают свою жизнь на стороне заказчика. Их сбор (gathering) 
и выявление (elicitation) осуществляются с помощью следующих основных технике 
(рисунок 2.2.4). 


Интервью. Самый универсальный путь выявления требований, заключаю- 
щийся в общении проектного специалиста (как правило, специалиста по бизнес- 
анализу) и представителя заказчика (или эксперта, пользователя и т.д.). Интервью 
может проходить в классическом понимании этого слова (беседа в виде «вопрос- 
ответ»), в виде переписки и т.п. Главным здесь является то, что ключевыми фигу- 
рами выступают двое — интервьюируемый и интервьюер (хотя это и не исключает 
наличия «аудитории слушателей», например, в виде лиц, поставленных в копию 
переписки). 


Работа с фокусными группами. Может выступать как вариант «расширен- 
ного интервью», где источником информации является не одно лицо, а группа лиц 
(как правило, представляющих собой целевую аудиторию, и/или обладающих важ- 
ной для проекта информацией, и/или уполномоченных принимать важные для про- 
екта решения). 


Работа с фокусными 
группами 


Интервью Анкетирование 






Семинары и 


_ Наблюдение Прототипирование 
мозговой штурм 


Моделирование 
Анализ документов процессов и 
взаимодействий 


Самостоятельное 
описание 


Рисунок 2.2.4 — Основные техники сбора и выявления требований 


Анкетирование. Этот вариант выявления требований вызывает много спо- 
ров, т.к. при неверной реализации может привести к нулевому результату при объ- 
ёмных затратах. В то же время при правильной организации анкетирование позво- 
ляет автоматически собрать и обработать огромное количество ответов от огром- 
ного количества респондентов. Ключевым фактором успеха является правильное 
составление анкеты, правильный выбор аудитории и правильное преподнесение 
анкеты. 


Семинары и мозговой штурм. Семинары позволяют группе людей очень 
быстро обменяться информацией (и наглядно продемонстрировать те или иные 
идеи), а также хорошо сочетаются с интервью, анкетированием, прототипирова- 
нием и моделированием — в том числе для обсуждения результатов и формирова- 
ния выводов и решений. Мозговой штурм может проводиться и как часть семинара, 
и как отдельный вид деятельности. Он позволяет за минимальное время сгенери- 





65 Здесь можно почитать подробнее о том, в чём разница между сбором и выявлением требований: «Requirements Gathering 
vs. Elicitation» (Laura Brandenburg): http:/www.bridging-the-gap.com/requirements-gathering-vs-elicitation/ 
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ровать большое количество идей, которые в дальнейшем можно не спеша рассмот- 
реть с точки зрения их использования для развития проекта. 


Наблюдение. Может выражаться как в буквальном наблюдении за некими 
процессами, так и во включении проектного специалиста в эти процессы в качестве 
участника. С одной стороны, наблюдение позволяет увидеть то, о чём (по совер- 
шенно различным соображениям) могут умолчать интервьюируемые, анкетируе- 
мые и представители фокусных групп, но с другой — отнимает очень много времени 
и чаще всего позволяет увидеть лишь часть процессов. 


Прототипирование. Состоит в демонстрации и обсуждении промежуточных 
версий продукта (например, дизайн страниц сайта может быть сначала представ- 
лен в виде картинок, и лишь затем свёрстан). Это один из лучших путей поиска 
единого понимания и уточнения требований, однако он может привести к серьёз- 
ным дополнительным затратам при отсутствии специальных инструментов (позво- 
ляющих быстро создавать прототипы) и слишком раннем применении (когда требо- 
вания ещё не стабильны, и высока вероятность создания прототипа, имеющего 
мало общего с тем, что хотел заказчик). 


Анализ документов. Хорошо работает тогда, когда эксперты в предметной 
области (временно) недоступны, а также в предметных областях, имеющих обще- 
принятую устоявшуюся регламентирующую документацию. Также к этой технике от- 
носится и просто изучение документов, регламентирующих бизнес-процессы в 
предметной области заказчика или в конкретной организации, что позволяет при- 
обрести необходимые для лучшего понимания сути проекта знания. 


Моделирование процессов и взаимодействий. Может применяться как к 
«бизнес-процессам и взаимодействиям» (например: «договор на закупку формиру- 
ется отделом закупок, визируется бухгалтерией и юридическим отделом...»), 
так и к «техническим процессам и взаимодействиям» (например: «платёжное по- 
ручение генерируется модулем “Бухгалтерия” шифруется модулем “Безопас- 
ность” и передаётся на сохранение в модуль “Хранилище”»). Данная техника тре- 
бует высокой квалификации специалиста по бизнес-анализу, т.к. сопряжена с обра- 
боткой большого объёма сложной (и часто плохо структурированной) информации. 


Самостоятельное описание. Является не столько техникой выявления тре- 
бований, сколько техникой их фиксации и формализации. Очень сложно (и даже 
нельзя!) пытаться самому «придумать требования за заказчика», но в спокойной 
обстановке можно самостоятельно обработать собранную информацию и акку- 
рати оформить её для дальнейшего обсуждения и уточнения. 





асто специалисты по бизнес-анализу приходят в свою профессию из те- 
_стирования. Если вас заинтересовало это направление, стоит ознако- , 
‚ миться со следующими книгами: 
e «Требования для программного обеспечения: рекомендации по сбору и | 
’ документированию» (Илья Корнипаев). | 
е «Business Analysis Techniques. 72 Essential Tools for Success» (James 

’ Саае, Debra Paul, Paul Turner). 

е «Business Analysis (Second Edition)» (Debra Paul, Donald Yeates, James 
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2.2.4. Уровни и типы требований 


Форма представления, степень детализации и перечень полезных свойств 
требований зависят от уровней и типов требований, которые схематично пред- 
ставлены на рисунке 2.2.е*7. 


Бизнес-требования (business гедиігетепїіѕё) выражают цель, ради которой 
разрабатывается продукт (зачем вообще он нужен, какая от него ожидается польза, 
как заказчик с его помощью будет получать прибыль). Результатом выявления тре- 
бований на этом уровне является общее видение (vision and ѕсорев) — документ, 
который, как правило, представлен простым текстом и таблицами. Здесь нет дета- 
лизации поведения системы и иных технических характеристик, но вполне могут 
быть определены приоритеты решаемых бизнес-задач, риски и т.п. 

Несколько простых, изолированных от контекста и друг от друга примеров 
бизнес-требований: 

• Нужен инструмент, в реальном времени отображающий наиболее выгод- 
ный курс покупки и продажи валюты. 

• Необходимо в два-три раза повысить количество заявок, обрабатывае- 
мых одним оператором за смену. 

• Нужно автоматизировать процесс выписки товарно-транспортных 
накладных на основе договоров. 
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Рисунок 2.2.е — Уровни и типы требований 























66 Очень подробное описание уровней и типов требований (а также их применения) можно найти в статье «Software Require- 
ments Engineering: What, Why, Who, When, апа Ном», Linda Westfall [http://www.westfallteam.com/Pa- 
pers/The_Why_What_Who_When_and_How_Of_Software__Requirements.pdf] 

67 В основу данного рисунка положены идеи, представленные в книге «Software Requirements (3' edition)» (Karl Wiegers апа 
Јоу Beatty). 

68 Business requirement. Anything that describes the financial, marketplace, ог other business benefit that either customers ог the 
developing organization wish to gain from the product. [«Software Requirements (3" edition)», Karl Wiegers апа Joy Beatty] 

69 Vision and scope. The vision and scope document collects the business requirements into a single deliverable that sets the stage 
for the subsequent development work. [«Software Requirements (3" edition)», Karl Wiegers and Joy Beatty] 
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Пользовательские требования (user requirements”) описывают задачи, KO- 
торые пользователь может выполнять с помощью разрабатываемой системы (ре- 
акцию системы на действия пользователя, сценарии работы пользователя). По- 
скольку здесь уже появляется описание поведения системы, требования этого 
уровня могут быть использованы для оценки объёма работ, стоимости проекта, 
времени разработки и т.д. Пользовательские требования оформляются в виде ва- 
риантов использования (use cases”), пользовательских историй (user $юпез?>), 
пользовательских сценариев (user ѕсепагіоѕ”з). (Также см. создание пользователь- 
ских сценариев“ в процессе выполнения тестирования.) 

Несколько простых, изолированных от контекста и друг от друга примеров 
пользовательских требований: 

e При первом входе пользователя в систему должно отображаться лицен- 
зионное соглашение. 

e Администратор должен иметь возможность просматривать список всех 
пользователей, работающих в данный момент в системе. 

e При первом сохранении новой статьи система должна выдавать запрос 
на сохранение в виде черновика или публикацию. 


Бизнес-правила (business гиІеѕ”*) описывают особенности принятых в пред- 
метной области (и/или непосредственно у заказчика) процессов, ограничений и 
иных правил. Эти правила могут относиться к бизнес-процессам, правилам работы 
сотрудников, нюансам работы ПО ит.д. 

Несколько простых, изолированных от контекста и друг от друга примеров 
бизнес-правил: 

e Никакой документ, просмотренный посетителями сайта хотя бы один 
раз, не может быть отредактирован или удалён. 

• Публикация статьи возможна только после утверждения главным редак- 
тором. 

• Подключение к системе извне офиса запрещено в нерабочее время. 


Атрибуты качества (quality аїїпбиїе$*) расширяют собой нефункциональ- 
ные требования и на уровне пользовательских требований могут быть представ- 
лены в виде описания ключевых для проекта показателей качества (свойств про- 
дукта, не связанных с функциональностью, но являющихся важными для достиже- 
ния целей создания продукта — производительность, масштабируемость, восста- 
навливаемость). Атрибутов качества очень много’, но для любого проекта реально 
важными является лишь некоторое их подмножество. 

Несколько простых, изолированных от контекста и друг от друга примеров 
атрибутов качества: 

• Максимальное время готовности системы к выполнению новой команды 





70 User requirement. User requirements are general statements of user goals ог business tasks that users need to perform. [«Soft- 
ware Requirements (3' edition)», Karl Wiegers апа Joy Beatty] 

71 Use case. A sequence of transactions in a dialogue between an actor and a component or system with a tangible result, where an 
actor can be a user or anything that can exchange information with the system. [ISTQB Glossary] 

72 User story. A high-level user or business requirement commonly used in agile software development, typically consisting of one 
or more sentences in the everyday or business language capturing what functionality a user needs, any non-functional criteria, 
and also includes acceptance criteria. [ISTQB Glossary] 

73 A scenario is a hypothetical story, used to help a person think through a complex problem or system. «An Introduction to Scenario 
Testing», Cem Kaner. [http://www.kaner.com/pdfs/ScenariolntroVer4.pdf] 

74 Business rule. A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert 
business structure or to control or influence the behavior of the business. A business rule expresses specific constraints on the 
creation, updating, and removal of persistent data in an information system. [«Defining Business Rules — What Are They Really», 
David Hay n ap.] 

75 Quality attribute. A feature or characteristic that affects ап item’s quality. [ISTQB Glossary] 

76 Даже в Википедии их список огромен: http://en.wikipedia.org/wiki/List_of_system_quality_attributes 
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после отмены предыдущей не может превышать одну секунду. 

e Внесённые в текст статьи изменения не должны быть утеряны при Hapy- 
шении соединения между клиентом и сервером. 

e Приложение должно поддерживать добавление произвольного количества 
неиероглифических языков интерфейса. 


Функциональные требования (functional requirements”) описывают поведе- 
ние системы, т.е. её действия (вычисления, преобразования, проверки, обработку 
и т.д.). В контексте проектирования функциональные требования в основном вли- 
яют на дизайн системы. 

Стоит помнить, что к поведению системы относится не только то, что система 
должна делать, но и то, что она не должна делать (например: «приложение не 
должно выгружать из оперативной памяти фоновые документы в течение 30 минут 
с момента выполнения с ними последней операции»). 

Несколько простых, изолированных от контекста и друг от друга примеров 
функциональных требований: 

e В процессе инсталляции приложение должно проверять остаток свобод- 
ного места на целевом носителе. 

• Система должна автоматически выполнять резервное копирование дан- 
ных ежедневно в указанный момент времени. 

• Электронный адрес пользователя, вводимый при регистрации, должен 
быть проверен на соответствие требованиям ВЕС822. 


Нефункциональные требования (non-functional гедиігетепіѕ”г) описывают 
свойства системы (удобство использования, безопасность, надёжность, расширяе- 
мость и т.д.), которыми она должна обладать при реализации своего поведения. 
Здесь приводится более техническое и детальное описание атрибутов качества. В 
контексте проектирования нефункциональные требования в основном влияют на 
архитектуру системы. 

Несколько простых, изолированных от контекста и друг от друга примеров 
нефункциональных требований: 

e При одновременной непрерывной работе с системой 1000 пользователей, 
минимальное время между возникновением сбоев должно быть более или 
равно 100 часов. 

e Ни при каких условиях общий объём используемой приложением памяти не 
может превышать 2 ГБ. 

• Размер шрифта для любой надписи на экране должен поддерживать 
настройку в диапазоне от 5 до 15 пунктов. 


Следующие требования в общем случае могут быть отнесены к нефункцио- 
нальным, однако их часто выделяют в отдельные подгруппы (здесь для простоты 
рассмотрены лишь три таких подгруппы, но их может быть и гораздо больше; как 
правило, они проистекают из атрибутов качества, но высокая степень детализации 
позволяет отнести их к уровню требований к продукту). 





77 Functional requirement. А requirement that specifies а function that а component ог system must perform. [ISTQB Glossary] 
Functional requirements describe the observable behaviors the system will exhibit under certain conditions and the actions the 
system will let users take. [«Software Requirements (3" edition)», Karl Wiegers and Joy Beatty] 

78 Non-functional requirement. A requirement that does not relate to functionality, but to attributes such as reliability, efficiency, 
usability, maintainability and portability. [ISTQB Glossary] 
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Ограничения (limitations, constraints?) представляют собой факторы, ограни- 
чивающие выбор способов и средств (в том числе инструментов) реализации про- 
дукта. 

Несколько простых, изолированных от контекста и друг от друга примеров 
ограничений: 

e Все элементы интерфейса должны отображаться без прокрутки при раз- 
решениях экрана от 800х600 до 1920х1080. 

e Не допускается использование Flash при реализации клиентской части 
приложения. 

e Приложение должно сохранять способность реализовывать функции с 
уровнем важности «критический» при отсутствии у клиента поддержки 

JavaScript. 


Требования к интерфейсам (external interfaces requirements®) описывают 
особенности взаимодействия разрабатываемой системы с другими системами и 
операционной средой. 

Несколько простых, изолированных от контекста и друг от друга примеров 
требований к интерфейсам: 

e Обмен данными между клиентской и серверной частями приложения при 
осуществлении фоновых АЈАХ-запросов должен быть реализован в фор- 
мате JSON. 

• Протоколирование событий должно вестись в журнале событий операци- 
онной системы. 

e Соединение с почтовым сервером должно выполняться согласно ВЕСЗ207 
(«SMTP over TLS»). 


Требования к данным (data гедигетеп{$') описывают структуры данных (и 
сами данные), являющиеся неотъемлемой частью разрабатываемой системы. Ча- 
сто сюда относят описание базы данных и особенностей её использования. 

Несколько простых, изолированных от контекста и друг от друга примеров 
требований к данным: 

e Все данные системы, за исключением пользовательских документов, 
должны храниться в БД под управлением СУБД MySQL, пользовательские 
документы должны храниться в БД под управлением СУБД MongoDB. 

• Информация о кассовых транзакциях за текущий месяц должна храниться 
в операционной таблице, а по завершении месяца переноситься в архив- 
ную. 

• Для ускорения операций поиска по тексту статей и обзоров должны быть 
предусмотрены полнотекстовые индексы на соответствующих полях 
таблиц. 





79 Limitation, constraint. Design and implementation constraints legitimately restrict the options available to the developer. [«Soft- 
ware Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 

80 External interface requirements. Requirements in this category describe the connections between the system and the rest of the 
universe. They include interfaces to users, hardware, and other software systems. [«Software Requirements (3rd edition)», Karl 
Wiegers and Joy Beatty] 

81 Data requirements. Data requirement describe the format, data type, allowed values, or default value for a data element; the 
composition of a complex business data structure; or a report to be generated. [«Software Requirements (3rd edition)», Karl 
Wiegers and Joy Beatty] 
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Спецификация требований (software requirements specification, SRS!82) объ- 
единяет в себе описание всех требований уровня продукта и может представлять 
собой весьма объёмный документ (сотни и тысячи страниц). 

Поскольку требований может быть очень много, а их приходится не только 
единожды написать и согласовать между собой, но и постоянно обновлять, работу 
проектной команды по управлению требованиями значительно облегчают соответ- 
ствующие инструментальные средства (requirements management tools! 84). 





ля более глубокого понимания принципов создания, организации и nc- 
‚ пользования набора требований рекомендуется ознакомиться с фунда- 
‚ ментальной работой Карла Вигерса «Разработка требований к программ- 
‚ ному обеспечению» («Software Requirements (3rd Edition) (Developer Best 
‚ Practices)», Karl Wiegers, Joy Beatty). В этой же книге (в приложениях) при- | 
 ведены крайне наглядные учебные примеры документов, описывающих | 








82 Software requirements specification, SRS. SRS describes аз fully аз necessary {Не expected behavior of the software system. 
The SRS is used in development, testing, quality assurance, project management, and related project functions. People call this 
deliverable by many different names, including business requirements document, functional spec, requirements document, and 
others. [«Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 

83 Requirements management tool. A tool that supports the recording of requirements, requirements attributes (e.g. priority, 

knowledge responsible) and annotation, and facilitates traceability through layers of requirements and requirements change 

management. Some requirements management tools also provide facilities for static analysis, such as consistency checking and 
violations to predefined requirements rules. [ISTQB Glossary] 

Обширный список инструментальных средств управления требованиями МОЖНО найти здесь: 
http://makingofsoftware.com/resources/list-of-rm-tools 


84 
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2.2.5. Свойства качественных требований 


В процессе тестирования требований проверяется их соответствие опреде- 
лённому набору свойств (рисунок 2.2.1. 





Обязательность Актуальность 








Модифицируемость | / Атомарность 
Прослеживаемость | Завершённость 
Корректность и 


проверяемость 
Недвусмысленность | 
m- Выполнимость 
Непротиворечивость | 





























Проранжированность 





$ ? ? 


Важность Стабильность Срочность 


Рисунок 2.2.1 — Свойства качественного требования 








Завершённость (completeness). Требование является полным и закончен- 
ным с точки зрения представления в нём всей необходимой информации, ничто не 
пропущено по соображениям «это и так всем понятно». 

Типичные проблемы с завершённостью: 

• Отсутствуют нефункциональные составляющие требования или ссылки на 
соответствующие нефункциональные требования (например: «пароли 
должны храниться в зашифрованном виде» — каков алгоритм шифрова- 
ния?). 

e Указана лишь часть некоторого перечисления (например: «экспорт осу- 
ществляется в форматы PDF, РМС и т.д.» — что мы должны понимать под 
«и т.д.»?). 

e Приведённые ссылки неоднозначны (например: «см. выше» вместо «см. раз- 
дел 123.45.6»). 





Способы обнаружения проблем Способы устранения проблем 
Применимы почти все техники тестиро- | Как только было выяснено, что 
вания требований“, но лучше всего по- | чего-то не хватает, нужно полу- 
могает задавание вопросов и использо- | чить недостающую информа- 
вание графического представления раз- | цию и дописать её в требова- 
рабатываемой системы. Также очень по- | ния. Возможно, потребуется не- 
могает глубокое знание предметной об- | большая переработка требова- 
ласти, позволяющее замечать пропу- | ний. 
щенные фрагменты информации. 




















85 Each requirement must contain all the information necessary for {Не reader to understand it. In the case of functional requirements, 
this means providing the information the developer needs to be able to implement it correctly. No requirement or necessary 
information should be absent. [«Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 
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Атомарность, единичность (аіотісіїузѕ). Требование является атомарным, 
если его нельзя разбить на отдельные требования без потери завершённости и оно 
описывает одну и только одну ситуацию. 

Типичные проблемы с атомарностью: 

e В одном требовании, фактически, содержится несколько независимых 
(например: «кнопка “Restart” не должна отображаться при остановленном 
сервисе, окно “Год” должно вмещать не менее 20-ти записей о последних 
действиях пользователя» — здесь зачем-то в одном предложении описаны 
совершенно разные элементы интерфейса в совершенно разных кон- 
текстах). 

• Требование допускает разночтение в силу грамматических особенностей 
языка (например: «если пользователь подтверждает заказ и редактирует 
заказ или откладывает заказ, должен выдаваться запрос на оплату» — 
здесь описаны три разных случая, и это требование стоит разбить на три от- 
дельных во избежание путаницы). Такое нарушение атомарности часто вле- 
чёт за собой возникновение противоречивости. 

e В одном требовании объединено описание нескольких независимых ситуа- 
ций (например: «когда пользователь входит в систему, ему должно отоб- 
ражаться приветствие; когда пользователь вошёл в систему, должно 
отображаться имя пользователя; когда пользователь выходит из си- 
стемы, должно отображаться прощание» — все эти три ситуации заслужи- 
вают того, чтобы быть описанными отдельными и куда более детальными 
требованиями). 





Способы обнаружения проблем Способы устранения проблем 
Обдумывание, обсуждение с колле- | Переработка и структурирование 
гами и здравый смысл: если мы счи- | требований: разбиение их на раз- 
таем, что некий раздел требований | делы, подразделы, пункты, NOA- 
перегружен и требует декомпози- | пункты и т.д. 
ции, скорее всего, так и есть. 

















Непротиворечивость, последовательность (сопз!${епсу??). Требование не 
должно содержать внутренних противоречий и противоречий другим требованиям 
и документам. 


Типичные проблемы с непротиворечивостью: 

• Противоречия внутри одного требования (например: «после успешного 
входа в систему пользователя, не имеющего права входить в систему...» 
— тогда как он успешно вошёл в систему, если не имел такого права?) 

• Противоречия между двумя и более требованиями, между таблицей и тек- 
стом, рисунком и текстом, требованием и прототипом ит.д. (например: «712.а 
Кнопка “Close” всегда должна быть красной» и «36452.х Кнопка “Close” ece- 
гда должна быть синей» — так всё же красной или синей?) 

• Использование неверной терминологии или использование разных терминов 
для обозначения одного и того же объекта или явления (например: «в случае, 
если разрешение окна составляет менее 800х600...» — разрешение есть у 
экрана, у окна есть размер). 





86 Each requirement you write represents а single market need that you either satisfy ог fail to satisfy. А ме! written requirement is 
independently deliverable and represents an incremental increase in the value of your software. [«Writing Good Requirements 
— The Big Ten Rules», Tyner Blain: http://tynerblain.com/blog/2006/05/25/writing-good-requirements-the-big-ten-rules/] 

87 Consistent requirements don’t conflict with other requirements of the same type ог with higher-level business, user, or system 
requirements. [«Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 
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Способы обнаружения проблем Способы устранения проблем 
Лучше всего обнаружить противоречи- | После обнаружения противо- 
вость помогает хорошая память ©, но | речия нужно прояснить ситуа- 
даже при её наличии незаменимым ин- | цию с заказчиком и внести не- 
струментом является графическое пред- | обходимые правки в требова- 
ставление разрабатываемой системы, | ния. 
позволяющее представить всю ключевую 
информацию в виде единой согласован- 
ной схемы (на которой противоречия 
очень заметны). 

















Недвусмысленность (ипатбідиоиѕпеѕѕ%, clearness). Требование должно 
быть описано без использования жаргона, неочевидных аббревиатур и расплывча- 
тых формулировок, должно допускать только однозначное объективное понимание 
и быть атомарным в плане невозможности различной трактовки сочетания отдель- 
ных фраз. 

Типичные проблемы с недвусмысленностью: 

e Использование терминов или фраз, допускающих субъективное толкование 
(например: «приложение должно поддерживать передачу больших объёмов 
данных» — насколько «больших»?) Вот лишь небольшой перечень слов и 
выражений, которые можно считать верными признаками двусмысленности: 
адекватно (adequate), быть способным (be able їо), легко (easy), обеспечи- 
вать (provide for), как минимум (as а minimum), быть способным (be capable 
of), эффективно (effectively), своевременно (timely), применимо (as applica- 
ble), если возможно (if possible), будет определено позже (to be determined, 
TBD), по мере необходимости (as appropriate), если это целесообразно (if 
practical), но не ограничиваясь (but пої limited to), быть способно (capability of), 
иметь возможность (capability to), нормально (normal), минимизировать 
(minimize), максимизировать (maximize), оптимизировать (optimize), быстро 
(rapid), удобно (user-friendly), просто (simple), часто (often), обычно (usual), 
большой (large), гибкий (flexible), устойчивый (robust), по последнему слову 
техники (state-of-the-art), улучшенный (improved), результативно (efficient). 
Вот утрированный пример требования, звучащего очень красиво, но совер- 
шенно нереализуемого и непонятного: «В случае необходимости оптимиза- 
ции передачи больших файлов система должна эффективно использовать 
минимум оперативной памяти, если это возможно». 

• Использование неочевидных или двусмысленных аббревиатур без расшиф- 
ровки (например: «доступ к ФС осуществляется посредством системы 
прозрачного шифрования» и «ФС предоставляет возможность фиксиро- 
вать сообщения в их текущем состоянии с хранением истории всех изме- 
нений» — ФС здесь обозначает файловую систему? Точно? А не какой-ни- 
будь «Фиксатор Сообщений»?) 

• Формулировка требований из соображений, что нечто должно быть всем оче- 
видно (например: «Система конвертирует входной файл из формата PDF 
в выходной файл формата PNG» — и при этом автор считает совершенно 
очевидным, что имена файлов система получает из командной строки, а мно- 
гостраничный PDF конвертируется в несколько РМС-файлов, к именам KOTO- 
рых добавляется «раде-1», «раде-2» и т.д.). Эта проблема перекликается с 
нарушением корректности. 





88 Natural language is prone to two types of ambiguity. Опе type І сап spot myself, when | сап think of тоге than опе мау to interpret 
a given requirement. The other type of ambiguity is harder to catch. That’s when different people read the requirement and come 
up with different interpretations of it. [«Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 
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Способы обнаружения проблем 


Способы устранения проблем 





Увидеть в требованиях двусмыслен- 
ность хорошо помогают перечислен- 
ные выше слова-индикаторы. Столь 
же эффективным является проду- 
мывание проверок: очень тяжело 
придумать объективную проверку 
для требования, допускающего раз- 
ночтение. 


Самый страшный враг двусмыслен- 
ности — числа и формулы: если что- 
то можно выразить в формульном 
или числовом виде (вместо словес- 
ного описания), обязательно стоит 
это сделать. Если это невозможно, 
стоит хотя бы использовать макси- 
мально точные технические тер- 











мины, отсылки к стандартам и т.п. 





Выполнимость (їеаѕі0ііїїузә). Требование должно быть технологически Bbl- 
полнимым и реализуемым в рамках бюджета и сроков разработки проекта. 
Типичные проблемы с выполнимостью: 

e Так называемое «озолочение» (gold plating) — требования, которые крайне 
долго и/или дорого реализуются и при этом практически бесполезны для ко- 
нечных пользователей (например: «настройка параметров для подключе- 
ния к базе данных должна поддерживать распознавание символов из же- 
стов, полученных с устройств трёхмерного ввода»). 

e Технически нереализуемые на современном уровне развития технологий 
требования (например: «анализ договоров должен выполняться с примене- 
нием искусственного интеллекта, который будет выносить однозначное 
корректное заключение о степени выгоды от заключения договора»). 

e В принципе нереализуемые требования (например: «система поиска должна 
заранее предусматривать все возможные варианты поисковых запросов и 
кэшировать их результаты»). 





Способы обнаружения проблем 


Способы устранения проблем 





Увы, здесь есть только один путь: 
максимально нарабатывать опыт и 
исходить из него. Невозможно по- 
нять, что некоторое требование 
«стоит» слишком много или вовсе 
невыполнимо, если нет понимания 
процесса разработки ПО, понима- 
ния предметной области и иных со- 
путствующих знаний. 








При обнаружении невыполнимости 
требования не остаётся ничего дру- 
гого, как подробно обсудить ситуа- 
цию с заказчиком и/или изменить 
требование (возможно — отказаться 
от него), или пересмотреть условия 
выполнения проекта (сделав выпол- 
нение данного требования возмож- 
ным). 








Обязательность, нужность (обіідаїогіпеѕѕ) и актуальность (up-to-date). 
Если требование не является обязательным к реализации, оно должно быть просто 
исключено из набора требований. Если требование нужное, но «не очень важное», 
для указания этого факта используется указание приоритета (см. «проранжирован- 
ность по...»). Также исключены (или переработаны) должны быть требования, утра- 
тившие актуальность. 

Типичные проблемы с обязательностью и актуальностью: 

• Требование было добавлено «на всякий случай», хотя реальной потребности 
в нём не было и нет. 





89 It must be possible to implement each requirement within the known capabilities and limitations of the system and its operating 
environment, аз well as within project constraints of time, budget, and staff. [«Software Requirements (3rd edition)», Karl Wiegers 
and Joy Beatty] 

90 Each requirement should describe a capability that provides stakeholders with the anticipated business value, differentiates the 
product in the marketplace, or is required for conformance to an external standard, policy, or regulation. Every requirement 
should originate from a source that has the authority to provide requirements. [«Software Requirements (3rd edition)», Karl 
Wiegers and Joy Beatty] 





Тестирование программного обеспечения. Базовый курс. © ЕРАМ Systems, 2015-2021 Стр: 44/298 


Свойства качественных требований 





Требованию выставлены неверные значения приоритета по критериям важ- 


ности и/или срочности. 


Требование устарело, но не было переработано или удалено. 





Способы обнаружения проблем 


Способы устранения проблем 





Постоянный (периодический) пере- 
смотр требований (желательно - с 
участием заказчика) позволяет за- 
метить фрагменты, потерявшие ак- 
туальность или ставшие низкоприо- 


Переработка требований (с устране- 
нием фрагментов, потерявших акту- 
альность) и переработка фрагмен- 
тов, у которых изменился приоритет 
(часто изменение приоритета ведёт 


и кизменению формулировки требо- 
вания). 


ритетными. 














Прослеживаемость (їгасеабііїу°" 92). Прослеживаемость бывает вертикаль- 
ной (vertical traceability”) и горизонтальной (horizontal traceability”). Вертикальная 
позволяет соотносить между собой требования на различных уровнях требований, 
горизонтальная позволяет соотносить требование с тест-планом, тест-кейсами, ар- 
хитектурными решениями и т.д. 

Для обеспечения прослеживаемости часто используются специальные ин- 
струменты по управлению требованиями (requirements management tool) и/или 
матрицы прослеживаемости (traceability ташх®). 

Типичные проблемы с прослеживаемостью: 

• Требования не пронумерованы, не структурированы, не имеют оглавления, 
не имеют работающих перекрёстных ссылок. 

e При разработке требований не были использованы инструменты и техники 
управления требованиями. 

• Набор требований неполный, носит обрывочный характер с явными «пробе- 
лами». 





Способы обнаружения проблем 


Способы устранения проблем 





Нарушения прослеживаемости ста- 
новятся заметны в процессе работы 
с требованиями, как только у нас 
возникают остающиеся без ответа 
вопросы вида «откуда взялось это 
требование?», «где описаны сопут- 
ствующие (связанные) требова- 





ния?», «на что это влияет?». 





Переработка требований. Воз- 
можно, придётся даже менять струк- 
туру набора требований, но всё 
точно начнётся с расстановки мно- 
жества перекрёстных ссылок, позво- 
ляющих осуществлять быструю и 
прозрачную навигацию по набору 
требований. 











91 Traceability. Тһе ability to identify related items іп documentation апа software, such аз requirements with associated tests. 
[ISTQB Glossary] 

92 A traceable requirement can be linked both backward to its origin and forward to derived requirements, design elements, code that 
implements it, and tests that verify its implementation. [«Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 

93 Vertical traceability. The tracing of requirements through the layers of development documentation to components. [ISTQB Glos- 
sary] 

94 Horizontal traceability. The tracing of requirements for a test level through the layers of test documentation (e.g. test plan, test 
design specification, test case specification and test procedure specification or test script). [ISTQB Glossary] 

95 Requirements management tool. A tool that supports the recording of requirements, requirements attributes (e.g. priority, 
knowledge responsible) and annotation, and facilitates traceability through layers of requirements and requirements change 
management. Some requirements management tools also provide facilities for static analysis, such as consistency checking and 
violations to predefined requirements rules. [ISTQB Glossary] 

96 Traceability matrix. A two-dimensional table, which correlates two entities (e.g., requirements and test cases). The table allows 
tracing back and forth the links of one entity to the other, thus enabling the determination of coverage achieved and the assess- 
ment of impact of proposed changes. [ISTQB Glossary] 
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Модифицируемость (modifiability”7). Это свойство характеризует простоту 
внесения изменений в отдельные требования и в набор требований. Можно гово- 
рить о наличии модифицируемости в том случае, если при доработке требований 
искомую информацию легко найти, а её изменение не приводит к нарушению иных 
описанных в этом перечне свойств. 

Типичные проблемы с модифицируемостью: 

• Требования неатомарны (см. «атомарность») и непрослеживаемы (см. «про- 
слеживаемость»), а потому их изменение с высокой вероятностью порождает 
противоречивость (см. «непротиворечивость»). 

• Требования изначально противоречивы (см. «непротиворечивость»). В такой 
ситуации внесение изменений (не связанных с устранением противоречиво- 
сти) только усугубляет ситуацию, увеличивая противоречивость и снижая 
прослеживаемость. 

• Требования представлены в неудобной для обработки форме (например, не 
использованы инструменты управления требованиями, и в итоге команде 
приходится работать с десятками огромных текстовых документов). 





Способы обнаружения проблем 


Способы устранения проблем 





Если при внесении изменений в 
набор требований, мы сталкиваемся 
с проблемами, характерными для 
ситуации потери прослеживаемо- 
сти, значит — мы обнаружили про- 


Переработка требований с перво- 
степенной целью повысить их про- 
слеживаемость. Параллельно 
можно устранять иные обнаружен- 
ные проблемы. 


блему с модифицируемостью. 
Также модифицируемость ухудша- 
ется при наличии практически лю- 
бой из рассмотренных в данном раз- 
деле проблем с требованиями. 














Проранжированность по важности, стабильности, срочности (ranked?8 
ог importance, stability, priority). Важность характеризует зависимость успеха npo- 
екта от успеха реализации требования. Стабильность характеризует вероятность 
того, что в обозримом будущем в требование не будет внесено никаких изменений. 
Срочность определяет распределение во времени усилий проектной команды по 
реализации того или иного требования. 

Типичные проблемы с проранжированностью состоят в её отсутствии или не- 
верной реализации и приводят к следующим последствиям. 

• Проблемы с проранжированностью по важности повышают риск неверного 
распределения усилий проектной команды, направления усилий на второ- 
степенные задачи и конечного провала проекта из-за неспособности про- 
дукта выполнять ключевые задачи с соблюдением ключевых условий. 

• Проблемы с проранжированностью по стабильности повышают риск выпол- 
нения бессмысленной работы по совершенствованию, реализации и тести- 
рованию требований, которые в самое ближайшее время могут претерпеть 
кардинальные изменения (вплоть до полной утраты актуальности). 

• Проблемы с проранжированностью по срочности повышают риск нарушения 





97 То facilitate modifiability, avoid stating requirements redundantly. Repeating а requirement іп multiple places where it logically 
belongs makes the document easier to read but harder to maintain. The multiple instances of the requirement all have to be 
modified at the same time to avoid generating inconsistencies. Cross-reference related items in the SRS to help keep them 
synchronized when making changes. [«Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 

98 Prioritize business requirements according to which are most important to achieving the desired value. Assign an implementation 
priority to each functional requirement, user requirement, use case flow, or feature to indicate how essential it is to a particular 
product release. [«Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 
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желаемой заказчиком последовательности реализации функциональности и 
ввода этой функциональности в эксплуатацию. 





Способы устранения проблем 

Прямо в процессе обсуждения 
требований с заказчиком (во 
время пересмотра требований) 
стоит вносить правки в значе- 
ния показателей срочности, 
важности и стабильности об- 
суждаемых требований. 


Способы обнаружения проблем 
Как и в случае с актуальностью и обяза- 
тельностью требований, здесь лучшим 
способом обнаружения недоработок яв- 
ляется постоянный (периодический) пе- 
ресмотр требований (желательно — с 
участием заказчика), в процессе кото- 
рого можно обнаружить неверные значе- 
ния показателей срочности, важности и 
стабильности обсуждаемых требований. 

















Корректность (correctness) и проверяемость (уетйа Пу‘). Фактически 
эти свойства вытекают из соблюдения всех вышеперечисленных (или можно ска- 
зать, что они не выполняются, если нарушено хотя бы одно из вышеперечислен- 
ных). В дополнение можно отметить, что проверяемость подразумевает возмож- 
ность создания объективного тест-кейса (тест-кейсов), однозначно показывающего, 
что требование реализовано верно и поведение приложения в точности соответ- 
ствует требованию. 

К типичным проблемам с корректностью также можно отнести: 

e опечатки (особенно опасны опечатки в аббревиатурах, превращающие одну 
осмысленную аббревиатуру в другую также осмысленную, но не имеющую 
отношения к некоему контексту; такие опечатки крайне сложно заметить); 

e наличие неаргументированных требований к дизайну и архитектуре; 

e плохое оформление текста и сопутствующей графической информации, 
грамматические, пунктуационные и иные ошибки в тексте; 

e неверный уровень детализации (например, слишком глубокая детализация 
требования на уровне бизнес-требований или недостаточная детализация на 
уровне требований к продукту); 

• требования к пользователю, а не к приложению (например: «пользователь 
должен быть в состоянии отправить сообщение» — увы, мы не можем влиять 
на состояние пользователя). 





Способы обнаружения проблем Способы устранения проблем 





Поскольку здесь мы имеем дело с 
«интегральной» проблемой, обнару- 
живается она с использованием ра- 
нее описанных способов. Отдель- 
ных уникальных методик здесь нет. 








Внесение в требования необходи- 
мых изменений — от элементарной 
правки обнаруженной опечатки, до 
глобальной переработки всего 
набора требований. 












Хорошее краткое руководство по написанию качественных требований _ 
представлено в статье «Writing Good Requirements — Тһе Big Теп 
‚ Rules»™., | 








99 Each requirement must accurately describe а capability that will meet some stakeholder’s need апа must clearly describe {не 
functionality to be built. [«Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 

100 If a requirement isn't verifiable, deciding whether it was correctly implemented becomes a matter of opinion, not objective analysis. 
Requirements that are incomplete, inconsistent, infeasible, or ambiguous are also unverifiable. [«Software Requirements (3rd 
edition)», Karl Wiegers and Joy Beatty] 

101 «Writing Good Requirements — The Big Ten Rules», Tyner Blain [http://tynerblain.com/blog/2006/05/25/writing-good-require- 
ments-the-big-ten-rules/] 
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2.2.6. Техники тестирования требований 


Тестирование документации и требований относится к разряду нефункцио- 
нального тестирования (non-functional іеѕііпо'%). Основные техники такого тестиро- 
вания в контексте требований таковы. 


Взаимный просмотр (peer review). Взаимный просмотр («рецензирова- 
ние») является одной из наиболее активно используемых техник тестирования тре- 
бований и может быть представлен в одной из трёх следующих форм (по мере 
нарастания его сложности и цены): 

e Беглый просмотр (walkthrough) может выражаться как в показе автором 
своей работы коллегам с целью создания общего понимания и получения 
обратной связи, так и в простом обмене результатами работы между двумя 
и более авторами с тем, чтобы коллега высказал свои вопросы и замечания. 
Это самый быстрый, дешёвый и часто используемый вид просмотра. 

Для запоминания: аналог беглого просмотра — это ситуация, когда вы в 

школе с одноклассниками проверяли перед сдачей сочинения друг друга, 

чтобы найти описки и ошибки. 

e Технический просмотр (technical review) выполняется группой специали- 
стов. В идеальной ситуации каждый специалист должен представлять свою 
область знаний. Тестируемый продукт не может считаться достаточно каче- 
ственным, пока хотя бы у одного просматривающего остаются замечания. 
Для запоминания: аналог технического просмотра — это ситуация, когда не- 
кий договор визирует юридический отдел, бухгалтерия и т.д. 

• Формальная инспекция (іпѕресііоп'%) представляет собой структурирован- 
ный, систематизированный и документируемый подход к анализу документа- 
ции. Для его выполнения привлекается большое количество специалистов, 
само выполнение занимает достаточно много времени, и потому этот вари- 
ант просмотра используется достаточно редко (как правило, при получении 
на сопровождение и доработку проекта, созданием которого ранее занима- 
лась другая компания). 

Для запоминания: аналог формальной инспекции — это ситуация генераль- 

ной уборки квартиры (включая содержимое всех шкафов, холодильника, кла- 

ДОВКИ И т.д.). 


Вопросы. Следующей очевидной техникой тестирования и повышения каче- 
ства требований является (повторное) использование техник выявления требова- 
ний, а также (как отдельный вид деятельности) — задавание вопросов. Если хоть 
что-то в требованиях вызывает у вас непонимание или подозрение — задавайте 
вопросы. Можно спросить представителей заказчика, можно обратиться к справоч- 
ной информации. По многим вопросам можно обратиться к более опытным колле- 
гам при условии, что у них имеется соответствующая информация, ранее получен- 
ная от заказчика. Главное, чтобы ваш вопрос был сформулирован таким образом, 
чтобы полученный ответ позволил улучшить требования. 





102 Non-functional testing. Testing the attributes ої a component ог system that до not relate to functionality, e.g. reliability, efficiency, 
usability, maintainability and portability. [ISTQB Glossary] 

103 Peer review. A review of a software work product by colleagues of the producer of the product for the purpose of identifying 
defects and improvements. Examples are inspection, technical review and walkthrough. [ISTQB Glossary] 

104 Walkthrough. A step-by-step presentation by the author of a document in order to gather information and to establish a common 
understanding of its content. [ISTQB Glossary] 

105 Technical review. A peer group discussion activity that focuses on achieving consensus on the technical approach to be taken. 
[ISTQB Glossary] 

106 Inspection. A type of peer review that relies on visual examination of documents to detect defects, e.g. violations of development 
standards and non-conformance to higher level documentation. The most formal review technique and therefore always based 
on a documented procedure. [ISTQB Glossary] 
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Поскольку здесь начинающие тестировщики допускают уйму ошибок, рас- 
смотрим подробнее. В таблице 2.2.а приведено несколько плохо сформулирован- 
ных требований, а также примеров плохих и хороших вопросов. Плохие вопросы 


провоцируют на бездумные ответы, не содержащие полезной информации. 


Таблица 2.2.а — Пример плохих и хороших вопросов к требованиям 





Плохое требование 


Плохие вопросы 


Хорошие вопросы 





«Приложение должно 
быстро запускаться». 


«Насколько быстро?» (На это вы 
рискуете получить ответы в 
стиле «очень быстро», «макси- 
мально быстро», «нууу... просто 
быстро»). 

«А если не получится быстро?» 
(Этим вы рискуете просто уди- 
вить или даже разозлить заказ- 
чика.) 

«Всегда?» («Да, всегда». Хм, а 
вы ожидали другого ответа?) 


«Каково максимально допусти- 
мое время запуска приложения, 
на каком оборудовании и при ка- 
кой загруженности этого обору- 
дования операционной системой 
и другими приложениями? На до- 
стижение каких целей влияет 
скорость запуска приложения? 
Допускается ли фоновая за- 
грузка отдельных компонентов 
приложения? Что является кри- 
терием того, что приложение за- 
кончило запуск?» 





«Опционально должен 
поддерживаться экспорт 
документов в формат 
РОР». 


«Любых документов?» (Ответы 
«да, любых» или «нет, только от- 
крытых» вам всё равно не помо- 
гут.) 

«В РОЕ какой версии должен 
производиться экспорт?» (Сам 
по себе вопрос хорош, но он не 
даёт понять, что имелось в виду 
под «опционально».) 

«Зачем?» («Нужно!» Именно так 
хочется ответить, если вопрос не 
раскрыт полностью.) 


«Насколько возможность экс- 
порта в PDF важна? Как часто, 
кем и с какой целью она будет nc- 
пользоваться? Является ли PDF 
единственным допустимым фор- 
матом для этих целей или есть 
альтернативы? Допускается ли 
использование внешних утилит 
(например, виртуальных PDF- 
принтеров) для экспорта доку- 
ментов в PDF?» 





«Если дата события не 
указана, она выбирается 
автоматически». 








«А если указана?» (То она ука- 
зана. Логично, не так ли?) 

«А если дату невозможно вы- 
брать автоматически?» (Сам во- 
прос интересен, но без поясне- 
ния причин невозможности зву- 
чит как издёвка.) 

«А если у события нет даты?» 
(Тут автор вопроса, скорее всего, 
хотел уточнить, обязательно ли 
это поле для заполнения. Но из 
самого требования видно, что 
обязательно: если оно не запол- 
нено человеком, его должен за- 
полнить компьютер.) 





«Возможно, имелось в виду, что 
дата генерируется автоматиче- 
ски, а не выбирается? Если да, 
то по какому алгоритму она гене- 
рируется? Если нет, то из какого 
набора выбирается дата и как ге- 
нерируется этот набор? P.S. Воз- 
можно, стоит использовать теку- 
щую дату?» 








Тест-кейсы и чек-листы. Мы помним, что хорошее требование является 
проверяемым, а значит, должны существовать объективные способы определения 
того, верно ли реализовано требование. Продумывание чек-листов или даже пол- 
ноценных тест-кейсов в процессе анализа требований позволяет нам определить, 
насколько требование проверяемо. Если вы можете быстро придумать несколько 
пунктов чек-листа, это ещё не признак того, что с требованием всё хорошо (напри- 
мер, оно может противоречить каким-то другим требованиям). Но если никаких 
идей по тестированию требования в голову не приходит — это тревожный знак. 
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Рекомендуется для начала убедиться, что вы понимаете требование (в том 
числе прочесть соседние требования, задать вопросы коллегам и т.д.). Также 
можно пока отложить работу с данным конкретным требованием и вернуться к нему 
позднее — возможно, анализ других требований позволит вам лучше понять и это 
конкретное. Но если ничто не помогает — скорее всего, с требованием что-то не 
так. 

Справедливости ради надо отметить, что на начальном этапе проработки 
требований такие случаи встречаются очень часто — требования сформированы 
очень поверхностно, расплывчато и явно нуждаются в доработке, т.е. здесь нет 
необходимости проводить сложный анализ, чтобы констатировать непроверяе- 
мость требования. 

На стадии же, когда требования уже хорошо сформулированы и протестиро- 
ваны, вы можете продолжать использовать эту технику, совмещая разработку тест- 
кейсов и дополнительное тестирование требований. 


Исследование поведения системы. Эта техника логически вытекает из 
предыдущей (продумывания тест-кейсов и чек-листов), но отличается тем, что 
здесь тестированию подвергается, как правило, не одно требование, а целый 
набор. Тестировщик мысленно моделирует процесс работы пользователя с систе- 
мой, созданной по тестируемым требованиям, и ищет неоднозначные или вовсе 
неописанные варианты поведения системы. Этот подход сложен, требует доста- 
точной квалификации тестировщика, но способен выявить нетривиальные недора- 
ботки, которые почти невозможно заметить, тестируя требования по отдельности. 


Рисунки (графическое представление). Чтобы увидеть общую картину тре- 
бований целиком, очень удобно использовать рисунки, схемы, диаграммы, интел- 
лект-карты!7 и т.д. Графическое представление удобно одновременно своей 
наглядностью и краткостью (например, ЧМ! -схема базы данных, занимающая один 
экран, может быть описана несколькими десятками страниц текста). На рисунке 
очень легко заметить, что какие-то элементы «не стыкуются», что где-то чего-то не 
хватает ит.д. Если вы для графического представления требований будете исполь- 
зовать общепринятую нотацию (например, уже упомянутый ОМІ), вы получите go- 
полнительные преимущества: вашу схему смогут без труда понимать и дорабаты- 
вать коллеги, а в итоге может получиться хорошее дополнение к текстовой форме 
представления требований. 


Прототипирование. Можно сказать, что прототипирование часто является 
следствием создания графического представления и анализа поведения системы. 
С использованием специальных инструментов можно очень быстро сделать 
наброски пользовательских интерфейсов, оценить применимость тех или иных ре- 
шений и даже создать не просто «прототип ради прототипа», а заготовку для даль- 
нейшей разработки, если окажется, что реализованное в прототипе (возможно, с 
небольшими доработками) устраивает заказчика. 





107 «Mind тар» [http://en.wikipedia.org/wiki/Mind тар] 
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2.2.7. Пример анализа и тестирования требований 


Поскольку наша задача состоит в том, чтобы сформировать понимание ло- 
гики анализа и тестирования требований, мы будем рассматривать предельно крат- 
кий и простой их набор. 





‚Отличный подробный пример требований можно найти в приложениях к | 
‚ книге Карла Вигерса «Разработка требований к программному обеспече- 
| нию» ИИСИ анне. (Зга Edition) (Developer Best Practices)», Karl 





O ii что у некоего клиента есть проблема: поступающие в огромном 
количестве его сотрудникам текстовые файлы приходят в разных кодировках, и со- 
трудники тратят много времени на перекодирование («ручной подбор кодировки»). 
Соответственно, он хотел бы иметь инструмент, позволяющий автоматически при- 
водить кодировки всех текстовых файлов к некоей одной. Итак, на свет появляется 
проект с кодовым названием «Конвертер файлов». 


Уровень бизнес-требований. Бизнес-требования (см. главу «Уровни и типы 
требований») изначально могут выглядеть так: «Необходим инструмент для AB- 
томатического приведения кодировок текстовых документов к одной». 

Здесь мы можем задать множество вопросов. Для удобства приведём как 
сами вопросы, так и предполагаемые ответы клиента. 


Задание 2.2.6: прежде чем читать приведённый ниже список вопросов, 
сформулируйте собственный. 











e В каких форматах представлены текстовые документы (обычный текст, 
НТМЕ, МО, что-то иное)? (Понятия не имею, я в этом не разбираюсь.) 

e В каких кодировках приходят исходные документы? (В разных.) 

e В какую кодировку нужно преобразовать документы? (В самую удобную и 
универсальную.) 

e На каких языках написан текст в документах? (Русский и английский.) 

e Откуда и как поступают текстовые документы (по почте, с сайтов, по сети, 
как-то иначе)? (Это неважно. Поступают отовсюду, но мы их складываем 
в одну папку на диске, нам так удобно.) 

e Каков максимальный объём документа? (Лара десятков страниц.) 

e Как часто появляются новые документы (например, сколько максимум доку- 
ментов может поступить за час)? (200-300 в час.) 

e С помощью чего сотрудники просматривают документы? (Notepad++.) 


Даже таких вопросов и ответов достаточно, чтобы переформулировать биз- 
нес-требования следующим образом (обратите внимание, что многие вопросы 
были заданы на будущее и не привели к появлению в бизнес-требованиях лишней 
технической детализации). 


Суть проекта: разработка инструмента, устраняющего проблему множе- 
ственности кодировок в текстовых документах, расположенных в локальном диско- 
вом хранилище. 


Цели проекта: 

• Исключение необходимости ручного подбора кодировок текстовых докумен- 
тов. 

• Сокращение времени работы с текстовым документом на величину, необхо- 
димую для ручного подбора кодировки. 
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Метрики достижения целей: 

• Полная автоматизация определения и преобразования кодировки текстового 
документа к заданной. 

e Сокращение времени обработки текстового документа в среднем на 1-2 mn- 
нуты на документ за счёт устранения необходимости ручного подбора коди- 
ровки. 


Риски: 
e Высокая техническая сложность безошибочного определения исходной KO- 
дировки текстового документа. 


Почему мы решили, что среднее время на подбор кодировки составляет 1—2 
минуты? Мы провели наблюдение. Также мы помним ответы заказчика на вопросы 
об исходных форматах документов, исходных и конечной кодировках (заказчик 
честно сказал, что не знает ответа), а потому мы попросили его предоставить нам 
доступ к хранилищу документов и выяснили: 

e Исходные форматы: plain text, HTML, МО. 
• Исходные кодировки: CP1251, UTF8, CP866, KOI8R. 
• Целевая кодировка: UTF8. 


На данном этапе мы вполне можем решить, что стоит заняться детализацией 
требований на более низких уровнях, т.к. появившиеся там вопросы позволят нам 
вернуться к бизнес-требованиям и улучшить их, если в этом возникнет необходи- 
МОСТЬ. 


Уровень пользовательских требований. Пришло время заняться уровнем 
пользовательских требований (см. главу «Уровни и типы требований»). Проект у 
нас несколько специфичный — результатами работы программного средства будет 
пользоваться большое количество людей, но само программное средство при этом 
они использовать не будут (оно будет просто выполнять свою работу «само по 
себе» — запущенное на сервере с хранилищем документов). Потому под пользова- 
телем здесь мы будем понимать человека, настраивающего работу приложения на 
сервере. 


Для начала мы создадим небольшую диаграмму вариантов использования, 
представленную на рисунке 2.2.0 (да, иногда её создают после текстового описа- 
ния требований, но иногда и до — нам сейчас удобнее сделать это сначала). В 
реальных проектах подобные схемы могут быть на несколько порядков более слож- 
ными и требующими подробной детализации каждого варианта использования. У 
нас же проект миниатюрный, потому схема получилась элементарной, и мы сразу 
переходим к описанию требований. 


Внимание! Это — ПЛОХИЕ требования. И мы далее будем их улучшать. 


Системные характеристики 
• СХ-1: Приложение является консольным. 
• СХ-2: Для работы приложение использует интерпретатор РНР. 
e СХ-3: Приложение является кроссплатформенным. 


Пользовательские требования 
e Также см. диаграмму вариантов использования. 
e ПТ-1: Запуск и остановка приложения. 
о ПТ-1.1: Запуск приложения производится из консоли командой «РНР 
сопуецег.рпр параметры». 
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О 


ПТ-2: 


ПТ-1.2: Остановка приложения производится выполнением команды 
Ctrl+C. 

Конфигурирование приложения. 

ПТ-2.1: Конфигурирование приложения сводится к указанию путей в 
файловой системе. 

ПТ-2.2: Целевой кодировкой является ОТЕ8. 

Просмотр журнала работы приложения. 

ПТ-3.1: В процессе работы приложение должно выводить журнал 
своей работы в консоль и лог-файл. 

ПТ-3.2: При первом запуске приложения лог-файл создаётся, а при по- 
следующих — дописывается. 








ис Primary Use Cases / 


сеа 





Приложение 


Остальные функции реализуются 
иными средствами и не 


предоставляются 
разрабаты ваемым приложением 







Конфигурирование 
приложения 


1 == 


Запуск приложения 


Остановка 
приложения 





Просмотр журнала 


работы приложения 











Рисунок 2.2.9 — Диаграмма вариантов использования 


Бизнес-правила 


БП-1: 
О 


Источник и приёмник файлов 

БП-1.1: Каталоги, являющиеся источником исходных и приёмником ко- 
нечных файлов не должны совпадать. 

БП-1.2: Каталог, являющийся приёмником конечных файлов, не может 
быть подкаталогом источника. 
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Атрибуты качества 
• АК-1: Производительность 
о АК-1.1: Приложение должно обеспечивать скорость обработки данных 
5 МБ/сек. 
e АК-2: Устойчивость к входным данным 
о АК-2.1: Приложение должно обрабатывать входные файлы размером 
до 50 МБ включительно. 
о АК-2.2: Если входной файл не является текстовым, приложение 
должно произвести обработку. 


Как будет сказано в главе «Типичные ошибки при анализе и тестировании 
требований» 9, не стоит изменять исходный формат файла и форматирование до- 
кумента, потому мы используем встроенные средства Word для отслеживания n3- 
менений и добавления комментариев. Примерный вид результата показан на ри- 
сунке 2.2.П. 





Системные характеристики Author 
e CX-1: Приложение является консольным —________________________ 1) Какая минимальная версия интерпретатора РНР 
_2- 22 т, поддерживается приложением? 
e СХ-2: Для работы приложение использует интерпретатор РНР. 229 __ А 2) Существует ли некая специфика настройки 
e СХ-3: Приложение является кроссплатформеннымі мА интерпретатора РНР для корректной работы 
AY, приложения” 
Пользовательские требования ш Ao Ашын 
e Также см. диаграмму вариантов использования. \ Должна ли в руководстве пользователя быть 
• ПТ-1: Запуск и остановка приложения. саана свн I ERRORE 
o ПТ-1.1: Запуск приложения производится из консоли командой *“PHPphp `` “тиште = 
converter.php параметры”. . | Author 
о ПТ-1.2: Остановка приложения производится выполнением команды `, `| Formatted: Russian 
Сіп+С в окне консоли, из которого было запущено приложение. з Author 
* ПТ-2: Конфигурирование приложения. | Какие ОС должны поддерживаться? В чём цель 
о ПТ-2.1: Конфигурирование приложения сводится к указанию путей в ` кроссплатформенности? 
файловой система в т 
2-5, Hir а --------------------------------4 Ф Author 
o ПТ-2.2: Целевой кодировкой является ОТЕ8 И үз Какие параметры передаются скрипту при 
e ПТ-3: Просмотр журнала работы приложения. о запуске? Какова реакция скрипта на: 


о ПТ-3.1: В процессе работы приложение должно выводить журнал своей ` ` `, + Отсутствие параметров. 


+. * Нав сол { 
работы в консоль и лог-файй и KEN . TEE r O E 


о ПТ-3.2: При первом запуске приложения лог-файл создаётся, а при T ыз йе 
“1 * r 
| Путей x чему? 


последующих – дописывается, 


Рисунок 2.2.1 — Использование средств Word для работы с требованиями 


К сожалению, мы не можем в данном тексте применить эти средства (резуль- 
тат будет отображаться некорректно, т.к. вы сейчас, скорее всего, читаете этот 
текст не в виде ООСХ-документа), а потому применим второй классический способ 
— будем вписывать свои вопросы и комментарии прямо внутрь текста требований. 

Проблемные места требований отмечены подчёркиванием, наши вопросы 
отмечены курсивом, предполагаемые ответы заказчика (даже, если точнее, техни- 
ческого специалиста заказчика) — жирным. В процессе анализа текст требований 
примет вот такой вид. 





(Е адание 2.2.с: проанализируйте предложенный набор требований с точки | 
| зрения свойств качественных требований“", сформулируйте свои BO- 
= ‚ просы заказчику, которые позволят улучшить этот набор требований. | 
Системные характеристики 
• СХ-1: Приложение является консольным. 
e СХ-2: Для работы приложение использует интерпретатор РНР. 
о Какая минимальная версия интерпретатора РНР поддерживается 
приложением? (5.5.х) 
о Существует ли некая специфика настройки интерпретатора РНР 
для корректной работы приложения? (Наверное, должен работать 
mbstring.) 
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о Настаиваете ли вы на реализации приложения именно на РНР? Если 
да, то почему. (Да, только РНР. У нас есть сотрудник, который его 
знает.) 

о Должна ли в руководстве пользователя быть описана процедура 
установки и настройки интерпретатора РНР? (Нет.) 

e СХ-3: Приложение является кроссплатформенным. 

о Какие ОС должны поддерживаться? (Любая, где работает РНР.) 

о В чём вообще цель кроссплатформенности? (Мы ещё не знаем, на 
чём будет работать сервер.) 


Пользовательские требования 
e Также см. диаграмму вариантов использования. 
e ПТ-1: Запуск и остановка приложения. 

о ПТ-1.1: Запуск приложения производится из консоли командой «РНР 
(возможно, здесь опечатка: должно быть рһр (в нижнем регистре)) 
(Да, ОК.) converter.php параметры». 

" Какие параметры передаются скрипту при запуске? (Каталог 
с исходными файлами, каталог с конечными файлами.) 
= Какова реакция скрипта на: 
• отсутствие параметров; (Пишет хелп.) 
• неверное количество параметров; (Пишет хелп и пояс- 
няет, что не так.) 
e неверные значения каждого из параметров. (Пишет 
хелп и поясняет, что не так.) 

о ПТ-1.2: Остановка приложения производится выполнением команды 
Ctrl+C (предлагаем дополнить это выражение фразой «в окне KOH- 
соли, из которого было запущено приложение») (Да, ОК.). 

e [1Т-2: Конфигурирование приложения. 

о ПТ-2.1: Конфигурирование приложения сводится к указанию путей в 

файловой системе. 
= Путей к чему? (Каталог с исходными файлами, каталог с KO- 
нечными файлами.) 

о ПТ-2.2: Целевой кодировкой является UTF8. 

= Предполагается ли указание иной целевой кодировки, или 
ОТЕ8 используется в качестве целевой всегда? (Только UTF8, 
других не надо.) 
e ПТ-З: Просмотр журнала работы приложения. 
о ПТ-3.1: В процессе работы приложение должно выводить журнал 
своей работы в консоль и лог-файл. 

= Каков формат журнала? (Дата-время, что и с чем делали, что 
получилось. Гляньте в логе апача, там нормально напи- 
сано.) 

= Различаются ли форматы журнала для консоли и лог-файла? 
(Нет.) 

= Как определяется имя лог-файла? (Третий параметр при 3a- 
пуске. Если не указан — пусть будет converter.log рядом с 
рһр-скриптом.) 

о ПТ-3.2: При первом запуске приложения лог-файл создаётся, а при по- 
следующих — дописывается. 

" Как приложение различает свой первый и последующие за- 
пуски? (Никак.) 
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= Какова реакция приложения на отсутствие лог-файла в cry- 
чае, если это не первый запуск? (Создаёт. Тут идея в том, 
чтобы оно не затирало старый лог — и всё.) 


Бизнес-правила 
• БП-1: Источник и приёмник файлов 

о БП-1.1: Каталоги, являющиеся источником исходным (опечатка, UC- 

ходных) (Да.) и приёмником конечных файлов, не должны совпадать. 
= Какова реакция приложения в случае совпадения этих катало- 
гов? (Пишет хелп и поясняет, что не так.) 

о БП-1.2: Каталог, являющийся приёмником конечных файлов, не может 
быть подкаталогом источника (предлагаем заменить слово «источ- 
ника» на фразу «каталога, являющегося источником исходных фай- 
лов»). (Хорошо, пусть будет так.) 


Атрибуты качества 
• АК-1: Производительность 
о АК-1.1: Приложение должно обеспечивать скорость обработки данных 


5 МБ/сек. 
= При каких технических характеристиках системы? (17, 4GB 
ВАМ) 


e АК-2: Устойчивость к входным данным 
о АК-2.1: Приложение должно обрабатывать входные файлы размером 
до 50 МБ включительно. 
= Какова реакция приложения на файлы, размер которых превы- 
шает 50 МБ? (Не трогает.) 
о АК-2.2: Если входной файл не является текстовым, приложение 
должно произвести обработку. 
= Обработку чего должно произвести приложение? (Этого 
файла. Не важно, что станет с файлом, лишь бы скрипт не 


умер.) 


Здесь есть несколько важных моментов, на которые стоит обратить внима- 
ние: 

e Ответы заказчика могут быть менее структурированными и последователь- 
ными, чем наши вопросы. Это нормально. Он может позволить себе такое, 
мы — нет. 

e Ответы заказчика могут содержать противоречия (в нашем примере сначала 
заказчик писал, что параметрами, передаваемыми из командной строки, яв- 
ляются только два имени каталога, а потом сказал, что там же указывается 
имя лог-файла). Это тоже нормально, т.к. заказчик мог что-то забыть или пе- 
репутать. Наша задача — свести эти противоречивые данные воедино (если 
это возможно) и задать уточняющие вопросы (если это необходимо). 

e В случае если с нами общается технический специалист, в его ответах 
вполне могут проскакивать технические жаргонизмы (как «хелп» в нашем 
примере). Не надо переспрашивать его о том, что это такое, если жаргонизм 
имеет однозначное общепринятое значение, но при доработке текста наша 
задача — написать то же самое строгим техническим языком. Если жарго- 
низм всё же непонятен — тогда лучше спросить (так, «хелп» — это всего 
лишь краткая помощь, выводимая консольными приложениями как подсказка 
о том, как их использовать). 
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Уровень продуктных требований (см. главу «Уровни и типы требова- 
ний»). Применим т.н. «самостоятельное описание» (см. главу «Источники и пути 
выявления требований») и улучшим требования. Поскольку мы уже получили 
много специфической технической информации, можно параллельно писать полно- 
ценную спецификацию требований. Во многих случаях, когда для оформления тре- 
бований используется простой текст, для удобства формируется единый документ, 
который интегрирует в себе как пользовательские требования, так и детальные спе- 
цификации. Теперь требования принимают следующий вид. 


Системные характеристики 

• СХ-1: Приложение является консольным. 

e СХ-2: Приложение разрабатывается на языке программирования РНР (при- 
чина выбора языка РНР отражена в пункте О-1 раздела «Ограничения», осо- 
бенности и важные настройки интерпретатора РНР отражены в пункте ДС-1 
раздела «Детальные спецификации»). 

e СХ-3: Приложение является кроссплатформенным с учётом пункта О-4 раз- 
дела «Ограничения». 


Пользовательские требования 
e Также см. диаграмму вариантов использования. 
e ПТ-1: Запуск и остановка приложения. 

о ПТ-1.1: Запуск приложения производится из консоли командой «рһр 
сопуегїіег.рһр SOURCE_DIR ОЕЅТІМАТІОМ РІВ [Об ЕПЕ МАМЕ] 
(описание параметров приведено в разделе ДС-2.1, реакция на 
ошибки при указании параметров приведена в разделах ДС-2.2, ДС- 
2.3, ДС-2.4). 

о ПТ-1.2: Остановка приложения производится выполнением команды 
Ctrl+C в окне консоли, из которого было запущено приложение. 

e ПТ-2: Конфигурирование приложения. 

о ПТ-2.1: Конфигурирование приложения сводится к указанию парамет- 
ров командной строки (см. ДС-2). 

о ПТ-2.2: Целевой кодировкой преобразования текстов является коди- 
ровка ОТЕ8 (также см. О-5). 

e ПТ-3: Просмотр журнала работы приложения. 

о ПТ-3.1: В процессе работы приложение должно выводить журнал 
своей работы в консоль и лог-файл (см. ДС-4), имя которого опреде- 
ляется правилами, указанными в ДС-2.1. 

о ПТ-3.2: Формат журнала работы и лог файла указан в ДС-4.1, а реак- 
ция приложения на наличие или отсутствие лог-файла указана в ДС- 
4.2 и ДС-4.3 соответственно. 


Бизнес-правила 
• БП-1: Источник и приёмник файлов 
о БП-1.1: Каталоги, являющиеся источником исходных и приёмником ко- 
нечных файлов, не должны совпадать (см. также ДС-2.1 и ДС-3.2). 
о БП-1.2: Каталог, являющийся приёмником конечных файлов, не может 
находиться внутри каталога, являющегося источником исходных фай- 
лов или его подкаталогов (см. также ДС-2.1 и ДС-3.2). 
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Атрибуты качества 
• АК-1: Производительность 
о АК-1.1: Приложение должно обеспечивать скорость обработки данных 
не менее 5 МБ/сек на аппаратном обеспечении, эквивалентном следу- 
ющему: процессор 17, 4 ГБ оперативной памяти, средняя скорость чте- 
ния/записи на диск 30 МБ/сек. Также см. О-6. 
e АК-2: Устойчивость к входным данным 
о АК-2.1: Требования относительно форматов обрабатываемых файлов 
изложены в ДС-5.1. 
о АК-2.2: Требования относительно размеров обрабатываемых файлов 
изложены в ДС-5.2. 
о АК-2.3: Поведение приложения в ситуации обработки файлов с нару- 
шениями формата определено в ДС-5.3. 


Ограничения 

• О-1: Приложение разрабатывается на языке программирования РНР, ис- 
пользование которого обусловлено возможностью заказчика осуществлять 
поддержку приложения силами собственного ІТ-отдела. 

e О-2: Ограничения относительно версии и настроек интерпретатора РНР от- 
ражены в пункте ДС-1 раздела «Детальные спецификации». 

• О-3: Процедуры установки и настройки интерпретатора РНР выходят за 
рамки данного проекта и не описываются в документации. 

e О-4: Кроссплатформенные возможности приложения сводятся к способности 
работать под ОС семейства Windows и Linux, поддерживающих работу ин- 
терпретатора РНР версии, указанной в ДС-1.1. 

e О-5: Целевая кодировка ЦТЕ8 является жёстко заданной, и её изменение в 
процессе эксплуатации приложения не предусмотрено. 

e О-6: Допускается невыполнение АК-1.1 в случае, если невозможность обес- 
печить заявленную производительность обусловлена объективными внеш- 
ними причинами (например, техническими проблемами на сервере заказ- 
чика). 


Созданные на основе таких пользовательских требований детальные специ- 
фикации имеют следующий вид. 


Детальные спецификации 
ДС-1: Интерпретатор РНР 
ДС-1.1: Минимальная версия — 5.5. 
ДС-1.2: Для работы приложения должно быть установлено и включено рас- 
ширение mbstring. 
ДС-2: Параметры командной строки 
ДС-2.1: При запуске приложения оно получает из командной строки три па- 
раметра: 
ЗОЧАСЕ_ ВІВ — обязательный параметр, определяет путь к каталогу 
с файлами, которые необходимо обработать; 
РЕЅТІМАТІОМ РІВ — обязательный параметр, определяет путь к Ka- 
талогу, в который необходимо поместить обработанные файлы (этот 
каталог не может находиться внутри каталога SOURCE_DIR или в его 
подкаталогах (см. БП-1.1 и БП-1.2)); 
Оа НЕ МАМЕ — необязательный параметр, определяет полное 
имя лог-файла (по умолчанию лог-файл с именем «сопуецег.\од» раз- 
мещается по тому же пути, по которому находится файл скрипта соп- 
уецег.рйр); 
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ДС-2.2: При указании недостаточного количества параметров командной 
строки приложение должно завершить работу, выдав сообщение об использовании 
(ДС-3.1). 

ДС-2.3: При указании излишнего количества параметров командной строки 
приложение должно игнорировать все параметры командной строки, кроме указан- 
ных в пункте ДС-2.1. 

ДС-2.4: При указании неверного значения любого из параметров командной 
строки приложение должно завершить работу, выдав сообщение об использовании 
(ДС-3.1), а также сообщив имя неверно указанного параметра, его значение и суть 
ошибки (см. ДС-3.2). 

ДС-3: Сообщения 

ДС-3.1: Сообщение об использовании: «USAGE сопуецег.рир SOURCE_DIR 
DESTINATION_DIR ОС ЕЕ МАМЕ». 

ДС-3.2: Сообщения об ошибках: 

Directory пої exists ог inaccessible. 
Destination dir may not reside within source dir tree. 
Wrong file name or inaccessible path. 

ДС-4: Журнал работы 

ДС-4.1: Формат журнала работы одинаков для отображения в консоли и за- 
писи в лог-файл: YYYY-MM-DD НН:1:$$ имя операции параметры операции pe- 
зультат_операции. 

ДС-4.2: В случае если лог-файл отсутствует, должен быть создан новый пу- 
стой лог-файл. 

ДС-4.3: В случае если лог-файл уже существует, должно происходить добав- 
ление новых записей в его конец. 

ДС-5: Форматы и размеры файлов 

ДС-5.1: Приложение должно обрабатывать текстовые файлы на русском и 
английском языках в следующих исходных кодировках: WIN1251, СР866, KOI8R. 

Обрабатываемые файлы могут быть представлены в следующих форматах, 
определяемых расширениями файлов: 

Plain Text (TXT); 
Hyper Text Markup Language Document (HTML); 
Mark Down Document (MD). 

ДС-5.2: Приложение должно обрабатывать файлы размером до 50 MB (вклю- 
чительно), игнорируя любой файл, размер которого превышает 50 МБ. 

ДС-5.3: Если файл с расширением из ДС-5.1 содержит внутри себя данные, 
не соответствующие формату файла, допускается повреждение таких данных. 





Задание 2.2.4: заметили ли вы, что в исправленном варианте требований 


‚ «потерялась» диаграмма вариантов использования (равно как и активная 





Итак, мы получили набор требований, с которым уже вполне можно работать. 
Он не идеален (и никогда вы не встретите идеальных требований), но он вполне 
пригоден для того, чтобы разработчики смогли реализовать приложение, а тести- 
ровщики — протестировать его. 


Задание 2.2.е: протестируйте этот набор требований и найдите в нём хот 
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2.2.8. Типичные ошибки при анализе и тестировании требований 


Для лучшего понимания и запоминания материала рассмотрим типичные 
ошибки, совершаемые в процессе анализа и тестирования требований. 


Изменение формата файла и документа. По какой-то непонятной причине 
очень многие начинающие тестировщики стремятся полностью уничтожить исход- 
ный документ, заменив текст таблицами (или наоборот), перенеся данные из Word 
в Ехсе! и т.д. Это можно сделать только в одном случае: если вы предварительно 
договорились о подобных изменениях с автором документа. В противном случае 
вы полностью уничтожаете чью-то работу, делая дальнейшее развитие документа 
крайне затруднительным. 

Самое худшее, что можно сделать с документом, — это сохранить его в итоге 
в некоем формате, предназначенном скорее для чтения, чем для редактирования 
(PDF, набор картинок и тому подобное). 

Если требования изначально создаются в некоей системе управления требо- 
ваниями, этот вопрос неактуален, но высокоуровневые требования большинство 
заказчиков привыкли видеть в обычном ООСХ-документе, а Мога предоставляет 
такие прекрасные возможности работы с документом, как отслеживание изменений 
(см. рисунок 2.2.1) и комментарии (см. рисунок 2.2.]). 


ВЕРЕКЕМСЕ$ MAILINGS REVIEW МЕМ ADD-INS 


ЕЕ ED. БВ Simple Markup = 
A a 























Show Markup ~ 
Show Track — 
PR ра Включить! 
Comments Changes ~ Э! Reviewing Р 
Comments 4 Track Changes 


Рисунок 2.2.1 — Активация отслеживания изменений B Word 


В итоге получается результат, представленный на рисунке 2.2.]: исходный 
формат сохраняется (а автор к нему уже привык), все изменения хорошо видны и 
могут быть приняты или отклонены в пару кликов мыши, а типичные часто повторя- 
ющиеся вопросы вы можете помимо указания в комментариях вынести в отдельный 
список и поместить его в том же документе. 


9.34.6 Если дата события не указана, она Выбирается автоматически. е, Author 
Возможно, имелось в виду, что дата генерируется 
автоматически, а не выбирается? 
* Если да: по какому алгоритму она 
генерируется? 
* Если нет: из какого набора выбирается дата и 
как генерируется этот набор? 
Р.5. Возможно, стоит использовать текущую дату? 
Author 
Formatted: Russian 





Рисунок 2.2.j — Правильно выглядящий документ с правками 


И ещё два маленьких, но неприятных момента относительно таблиц: 

• Выравнивание ВСЕГО текста в таблице по центру. Да, выравнивание по цен- 
тру хорошо смотрится в заголовках и ячейках с парой-тройкой слов, но если 
так выровнен весь текст, читать его становится сложно. 

• Отключение границ ячеек. Такая таблица намного хуже читается. 
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Отметка того факта, что с требованием всё в порядке. Если у вас не воз- 
никло вопросов и/или замечаний к требованию — не надо об этом писать. Любые 
пометки в документе подсознательно воспринимаются как признак проблемы, и та- 
кое «одобрение требований» только раздражает и затрудняет работу с документом 
— сложнее становится заметить пометки, относящиеся к проблемам. 


Описание одной и той же проблемы в нескольких местах. Помните, что 
ваши пометки, комментарии, замечания и вопросы тоже должны обладать свой- 
ствами хороших требований (настолько, насколько эти свойства к ним применимы). 
Если вы много раз в разных местах пишете одно и то же об одном и том же, вы 
нарушаете как минимум свойство модифицируемости. Постарайтесь в таком слу- 
чае вынести ваш текст в конец документа, укажите в нём же (в начале) перечень 
пунктов требований, к которым он относится, а в самих требованиях в коммента- 
риях просто ссылайтесь на этот текст. 


Написание вопросов и комментариев без указания места требования, к 
которым они относятся. Если ваше инструментальное средство позволяет ука- 
зать часть требования, к которому вы пишете вопрос или комментарий, сделайте 
это (например, Word позволяет выделить для комментирования любую часть TEk- 
ста — хоть один символ). Если это невозможно, цитируйте соответствующую часть 
текста. В противном случае вы порождаете неоднозначность или вовсе делаете 
вашу пометку бессмысленной, т.к. становится невозможно понять, о чём вообще 
идёт речь. 


Задавание плохо сформулированных вопросов. Эта ошибка была по- 
дробно рассмотрена выше (см. раздел «Техники тестирования требований»“® и 
таблицу 2.2.а“%). Однако добавим, что есть ещё три вида плохих вопросов: 

• Первый вид возникает из-за того, что автор вопроса не знает общепринятой 
терминологии или типичного поведения стандартных элементов интерфейса 
(например, «что такое чек-бокс?», «как в списке можно выбрать несколько 
пунктов?», «как подсказка может всплывать?»). 

e Второй вид плохих вопросов похож на первый из-за формулировок: вместо 
того, чтобы написать «что вы имеете в виду под {чем-то}?», автор вопроса 
пишет «что такое {что-то}?» То есть вместо вполне логичного уточнения по- 
лучается ситуация, очень похожая на рассмотренную в предыдущем пункте. 

• Третий вид сложно привязать к причине возникновения, но его суть в том, что 
к некорректному и/или невыполнимому требованию задаётся вопрос наподо- 
бие «что будет, если мы это сделаем?». Ничего не будет, т.к. мы это точно 
не сделаем. И вопрос должен быть совершенно иным (каким именно — зави- 
сит от конкретной ситуации, но точно не таким). 


И ещё раз напомним о точности формулировок: иногда одно-два слова могут 
на корню уничтожить отличную идею, превратив хороший вопрос в плохой. Срав- 
ните: «Что такое формат даты по умолчанию?» и «Каков формат даты по умолча- 
нию?». Первый вариант просто показывает некомпетентность автора вопроса, то- 
гда как второй — позволяет получить полезную информацию. 

К этой же проблеме относится непонимание контекста. Часто можно увидеть 
вопросы в стиле «о каком приложении идёт речь?», «что такое система?» и им по- 
добные. Чаще всего автор таких вопросов просто вырвал требование из контекста, 
по которому было совершенно ясно, о чём идёт речь. 
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Написание очень длинных комментариев и/или вопросов. История знает 
случаи, когда одна страница исходных требований превращалась в 20—30 страниц 
текста анализа и вопросов. Это плохой подход. Все те же мысли можно выразить 
значительно более кратко, чем сэкономить как своё время, так и время автора ис- 
ходного документа. Тем более стоит учитывать, что на начальных стадиях работы 
с требованиями они весьма нестабильны, и может получиться так, что ваши 5—10 
страниц комментариев относятся к требованию, которое просто удалят или изменят 
до неузнаваемости. 


Критика текста или даже его автора. Помните, что ваша задача — сделать 
требования лучше, а не показать их недостатки (или недостатки автора). Потому 
комментарии вида «плохое требование», «неужели вы не понимаете, как глупо это 
звучит», «надо переформулировать» неуместны и недопустимы. 


Категоричные заявления без обоснования. Как продолжение ошибки 
«критика текста или даже его автора» можно отметить и просто категоричные заяв- 
ления наподобие «это невозможно», «мы не будем этого делать», «это не нужно». 
Даже если вы понимаете, что требование бессмысленно или невыполнимо, эту 
мысль стоит сформулировать в корректной форме и дополнить вопросами, позво- 
ляющими автору документа самому принять окончательное решение. Например, 
«это не нужно» можно переформулировать так: «Мы сомневаемся в том, что дан- 
ная функция будет востребована пользователями. Какова важность этого требова- 
ния? Уверены ли вы в его необходимости?» 


Указание проблемы с требованиями без пояснения её сути. Помните, что 
автор исходного документа может не быть специалистом по тестированию или биз- 
нес-анализу. Потому просто пометка в стиле «неполнота», «двусмысленность» и 
т.д. могут ничего ему не сказать. Поясняйте свою мысль. 

Сюда же можно отнести небольшую, но досадную недоработку, относящуюся 
к противоречивости: если вы обнаружили некие противоречия, сделайте соответ- 
ствующие пометки во всех противоречащих друг другу местах, а не только в одном 
из них. Например, вы обнаружили, что требование 20 противоречит требованию 30. 
Тогда в требовании 20 отметьте, что оно противоречит требованию 30, и наоборот. 
И поясните суть противоречия. 


Плохое оформление вопросов и комментариев. Старайтесь сделать 
ваши вопросы и комментарии максимально простыми для восприятия. Помните не 
только о краткости формулировок, но и об оформлении текста (см., например, как 
на рисунке 2.2.] вопросы структурированы в виде списка — такая структура воспри- 
нимается намного лучше, чем сплошной текст). Перечитайте свой текст, исправьте 
опечатки, грамматические и пунктуационные ошибки и т.д. 


Описание проблемы не в том месте, к которому она относится. Класси- 
ческим примером может быть неточность в сноске, приложении или рисунке, кото- 
рая почему-то описана не там, где она находится, а в тексте, ссылающемся на со- 
ответствующий элемент. Исключением может считаться противоречивость, при ко- 
торой описать проблему нужно в обоих местах. 


Ошибочное восприятие требования как «требования к пользователю». 
Ранее (см. «Корректность» в «Свойства качественных требований») мы говорили, 
что требования в стиле «пользователь должен быть в состоянии отправить сооб- 
щение» являются некорректными. И это так. Но бывают ситуации, когда проблема 
намного менее опасна и состоит только в формулировке. Например, фразы в стиле 
«пользователь может нажать на любую из кнопок», «пользователю должно быть 
видно главное меню» на самом деле означают «все отображаемые кнопки должны 
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быть доступны для нажатия» и «главное меню должно отображаться». Да, эту недо- 
работку тоже стоит исправить, но не следует отмечать её как критическую про- 
блему. 


Скрытое редактирование требований. Эту ошибку можно смело отнести к 
разряду крайне опасных. Её суть состоит в том, что тестировщик произвольно вно- 
сит правки в требования, никак не отмечая этот факт. Соответственно, автор доку- 
мента, скорее всего, не заметит такой правки, а потом будет очень удивлён, когда 
в продукте что-то будет реализовано совсем не так, как когда-то было описано в 
требованиях. Потому простая рекомендация: если вы что-то правите, обязательно 
отмечайте это (средствами вашего инструмента или просто явно в тексте). И ещё 
лучше отмечать правку как предложение по изменению, а не как свершившийся 
факт, т.к. автор исходного документа может иметь совершенно иной взгляд на си- 
туацию. 


Анализ, не соответствующий уровню требований. При тестировании тре- 
бований следует постоянно помнить, к какому уровню они относятся, т.к. в против- 
ном случае появляются следующие типичные ошибки: 

• Добавление в бизнес-требования мелких технических подробностей. 

e Дублирование на уровне пользовательских требований части бизнес-требо- 
ваний (если вы хотите увеличить прослеживаемость набора требований, 
имеет смысл просто использовать ссылки). 

• Недостаточная детализация требований уровня продукта (общие фразы, до- 
пустимые, например, на уровне бизнес-требований, здесь уже должны быть 
предельно детализированы, структурированы и дополнены подробной тех- 
нической информацией). 
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2.3. Виды и направления тестирования 


2.3.1. Упрощённая классификация тестирования 


Тестирование можно классифицировать по очень большому количеству при- 
знаков, и практически в каждой серьёзной книге о тестировании автор показывает 
свой (безусловно имеющий право на существование) взгляд на этот вопрос. 

Соответствующий материал достаточно объёмен и сложен, а глубокое пони- 
мание каждого пункта в классификации требует определённого опыта, потому мы 
разделим данную тему на две: сейчас мы рассмотрим самый простой, минималь- 
ный набор информации, необходимый начинающему тестировщику, а в следующей 
главе приведём подробную классификацию. 

Используйте нижеприведённый список как очень краткую «шпаргалку для за- 
поминания». Итак, тестирование можно классифицировать: 
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Рисунок 2.3.а — Упрощённая классификация тестирования 


e По запуску кода на исполнение: 
о Статическое тестирование — без запуска. 
о Динамическое тестирование — с запуском. 


e По доступу к коду и архитектуре приложения: 
о Метод белого ящика — доступ к коду есть. 
о Метод чёрного ящика — доступа к коду нет. 
о Метод серого ящика — к части кода доступ есть, к части — нет. 


• По степени автоматизации: 
о Ручное тестирование — тест-кейсы выполняет человек. 
о Автоматизированное тестирование — тест-кейсы частично или полно- 
стью выполняет специальное инструментальное средство. 


e По уровню детализации приложения (по уровню тестирования): 
о Модульное (компонентное) тестирование — проверяются отдельные 
небольшие части приложения. 
о Интеграционное тестирование — проверяется взаимодействие между 
несколькими частями приложения. 
о Системное тестирование — приложение проверяется как единое це- 
лое. 


e По (убыванию) степени важности тестируемых функций (по уровню функци- 
онального тестирования): 

о Дымовое тестирование (обязательно изучите этимологию термина — 
хотя бы в Википедии!) — проверка самой важной, самой ключевой 
функциональности, неработоспособность которой делает бессмыс- 
ленной саму идею использования приложения. 





108 «Smoke test», Wikipedia [http://en.wikipedia.org/wiki/Smoke_testing_(electrical)] 
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о Тестирование критического пути — проверка функциональности, ис- 
пользуемой типичными пользователями в типичной повседневной де- 
ятельности. 

о Расширенное тестирование — проверка всей (остальной) функцио- 
нальности, заявленной в требованиях. 


e По принципам работы с приложением: 

о Позитивное тестирование — все действия с приложением выполня- 
ются строго по инструкции без никаких недопустимых действий, некор- 
ректных данных и т.д. Можно образно сказать, что приложение иссле- 
дуется в «тепличных условиях». 

о Негативное тестирование — в работе с приложением выполняются 
(некорректные) операции и используются данные, потенциально при- 
водящие к ошибкам (классика жанра — деление на ноль). 





| Внимание! Очень частая ошибка! Негативные тесты НЕ пред- 
‚ полагают возникновения в приложении ошибки. Напротив — 
‚ они предполагают, что верно работающее приложение paxe 
‚ в критической ситуации поведёт себя правильным образом (в 
примере с делением на ноль, например, отобразит сообще- 





Часто возникает вопрос о том, чем различаются «тип тестирования», «вид 
тестирования», «способ тестирования», «подход к тестированию» и т.д. и т.п. Если 
вас интересует строгий формальный ответ, посмотрите в направлении таких вещей 
как «таксономия!9» и «таксон!‘°», т.к. сам вопрос выходит за рамки тестирования 
как такового и относится уже к области науки. 

Но исторически так сложилось, что как минимум «тип тестирования» (testing 
type) и «вид тестирования» (testing Кіпа) давно стали синонимами. 





109 «Таксономия», Wikipedia [Һіїрѕ://ги.лиікіреаїа.оголмікі/ Таксономия] 
110 «Таксон», Wikipedia [https://ru.wikipedia.org/wiki/TakcoH] 
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2.3.2. Подробная классификация тестирования 
2.3.2.1. Схема классификации тестирования 


Теперь мы рассмотрим классификацию тестирования максимально по- 
дробно. Настоятельно рекомендуется прочесть не только текст этой главы, но и все 
дополнительные источники, на которые будут приведены ссылки. 

На рисунках 2.3.6 и 2.3.с приведена схема, на которой все способы класси- 
фикации показаны одновременно. Многие авторы, создававшие подобные класси- 
фикации""", использовали интеллект-карты, однако такая техника не позволяет в 
полной мере отразить тот факт, что способы классификации пересекаются (т.е. не- 
которые виды тестирования можно отнести к разным способам классификации). На 
рисунках 2.3.5 и 2.3.с самые яркие случаи таких пересечений отмечены цветом (см. 
полноразмерный электронный вид рисунка") и границей блоков в виде набора TO- 
чек. Если вы видите на схеме подобный блок — ищите одноимённый где-то в дру- 
гом виде классификации. 





астоятельно рекомендуется в дополнение к материалу этой главы Mpo- 

‚ честь: | 
 » прекрасную статью «Классификация видов тестирования» !!'; | 
• также классическую книгу Ли Коупленда «Практическое руководство по | 
разработке тестов» (Lee Copeland, «А Practitioner's Guide to Software | 
Test Design»); | 

• очень интересную заметку «Types ої Software Testing: List of 100 Differ- | 





Зачем вообще нужна классификация тестирования? Она позволяет упорядо- 
чить знания и значительно ускоряет процессы планирования тестирования и раз- 
работки тест-кейсов, а также позволяет оптимизировать трудозатраты за счёт того, 
что тестировщику не приходится изобретать очередной велосипед. 

При этом ничто не мешает создавать собственные классификации — как во- 
обще придуманные с нуля, так и представляющие собой комбинации и модифика- 
ции представленных ниже классификаций. 






‚ Если вас интересует некая «эталонная классификация», то... её не суще- 
ствует. Можно сказать, что в материалах"з ISTQB приведён наиболее _ 
‚ обобщённый и общепринятый взгляд на этот вопрос, но и там нет единой | 
‚ схемы, которая объединяла бы все варианты классификации. | 





| Так что, если вас просят рассказать о классификации тестирования, стоит | 
‚ уточнить, согласно какому автору или источнику спрашивающий ожидает · 





Сейчас вы приступите к изучению одного из самых сложных разделов этой 
книги. Если вы уже имеете достаточный опыт в тестировании, можете отталки- 
ваться от схемы, чтобы систематизировать и расширить свои знания. Если вы 
только начинаете заниматься тестированием, рекомендуется сначала прочитать 
текст, следующий за схемой. 





111 
112 


«Классификация видов тестирования» [ћіїр://һабгаһабг.ги/сотрапу/про-сотр/0109/223833/ 
«Types of Software Testing: List of 100 Different Testing Types» [http:/www.guru99.com/types-of-software-testing.html] 
113 International Software Testing Qualifications Board, Downloads. [http://www.istqb.org/downloads.html] 
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| По поводу схем, которые вы сейчас увидите на рисунках 2.3.6 и 2.3.с, ча- | 


сто поступают вопросы, почему функциональное и нефункциональное TE- ' 
' стирование не связано с соответствующими подвидами. Тому есть две | 
причины: 
1) Несмотря на то что те или иные виды тестирования принято причислять | 
K функциональному или нефункциональному тестированию, в них всё | 
равно присутствуют обе составляющие (как функциональная, так и не- 
‚ функциональная), пусть и в разных пропорциях. Более того: часто прове- | 
рить нефункциональную составляющую невозможно, пока не будет pea- | 
_ лизована соответствующая функциональная составляющая. | 
`2) Схема превратилась бы в непроглядную паутину линий. 


| Потому было решено оставить рисунки 2.3.6 и 2.3.с в том виде, в каком | 
‚ они представлены на следующих двух страницах. Полноразмерный вари- | 
нт этих рисунков можно скачать здесь"““. 








Итак, тестирование можно классифицировать... 





114 Полноразмерный вариант рисунков 2.3.6 [http://svyatoslav.biz/wp-pics/software_testing_classification _ru.png] и 2.3.с 
[http://svyatoslav.biz/wp-pics/software_testing_classification_en.png] 
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| Классификация тестирования 
— По запуску кода на исполнение — По доступу к коду и архитектуре приложения | По степени автоматизации 
| он ксн | 
Статическое Динамическое Метод белого Метод чёрного ‚ Метод серого | Ручное Автоматизированное 
тестирование тестирование ящика ящика ı Auma 1 (и «автоматическое») 
|| По уровню детализации приложения | | — По (убыванию) степени важности тестируемых 
(по уровню тестирования) функций (по уровню функционального тестирования) По природе приложения 
_ на о Я рсе | | | 
Системное Н 
тестирование | Расширенное | Веб Мобильное Настольное 
— По фокусировке на уровне архитектуры приложения По привлечению конечных пользователей По степени формализации 
Уровень Уровень Уровень Альфа- Гамма- f На основе tect- | · Исследова- 
представления бизнес-логики данных | тестирование | тестирование кейсов | тельское 
ти По целям и задачам По техникам и подходам 
Е По принципам работы | | | Шш | | 
с приложением Функциональное Инсталляционное Позитивное Негативное На основе (знания) источников ошибок 
п кы 
\озитивное Нефункциональное Регрессионное Ha ве опытатестиров: ч Предугадывание ошибок 
сценариев, чек-листов 
Негативное Е Повторное — Эвристическая оценка 
= Приёмочное = Добавление ошибок 
| 
| | По степени вмешательства в работу 
приложения 
] ] Мутационное 
По техникам 
— Удобства использования — Надёжности автоматизации г Инвазивное Неинвазивное 
= Ha основе среды выполнения 
= Доступности Восстанавливаемости ен 
На основе выбора входных данных 
Тестирование в процессе разработки 
—4 ыы Под управлением 
Интерфейса Отказоустойчивости ре 
словами —{| На основе классов эквивалентности 
Операционное тестирование 
m Безопасности Данных и баз данных 
Под управлением | 
поведением На основе граничных условий 
| Интернационализации Использования ресурсов На основе (моделей) поведения 
приложения 
На основе структур вое 
кода 
m Локализации По таблице принятия решений 
Производительности Попарное 
Выражений _ - -- 
По диаграмме или таблице 
состояний 
к Совместимости | Нагрузочное На основе ортогональных массивов Б. эы, элг эзан: ВИРОВЕ АНИР | 
Ветвей 
— По спецификациям 
Конфигурационное | Масштабируемости 
Условий — На основе кода 
По моделям поведения приложения 
L- Кроссбра; = Объё 
T аы Комбинаций = 
условий — о потоку управления 
На основе вариантов использования 
Стрессовое 
‚ Сравнительное Решений 4 По потоку данных 
Параллельное 
лы Решающих о диаграмме или таблице _ 
Г и иц 
Демонстрационное условий состояний 
с ——_————- m На основе случайных данных 
— Путей — Инспекция (аудит) кода 
А/В 
































4 По моменту выполнения (хронологии) 


























































































































| | 
Общая универсальная логика последовательности По концентрации внимания на требованиях и их 
тестирования Я ОЕ составляющих 
| 
Восходящее Тестирование м. роса 
функциональных ады 
Тестирование составляющих Кашы сайлады 
требований 
Типичные общие сценарии 
| | | 
Типичный общий сценарий 1 Типичный общий сценарий 2 Типичный общий сценарий 3 

`“Системное _ ~ Tamma- 
тестирование тестирование 





| тестирование 





= нете. 


Приёмочное тестирование 


} Гибридное тестирование 
Рисунок 2.3.6 — Подробная классификация тестирования (русскоязычный 
вариант) 
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Software testing classification 
— By code execution By access to application code and architecture |m By automation level 
А А А Я White box Black box 7 Gray box | Automated 
І | 
Static testing Dynamic testing method method | Мапиа! (+ automatic) 
|! Ву specification level By functions under test importance (decreasingly) UI эү 
(by testing level) (by functional testing level) By application nature 
а Integration А Critical path Р Web арр Mobile арр Desktop арр 
Unit testing testing System testing Smoke testing testing Extended testing testing testing testing 
4] Ву architecture tier By end users participation | Ву formalization level 
Presentation tier Business-logic i i Ы е се а. 
testing tier testing Data tier testing Alpha testing Beta testing Gamma testing Test case based Exploratory 
— By aims and goals — By techniques and approaches 
| ВУ 1 with Functional testing Installation testing Positive testing Negative testing By error source (knowledge) 
|: Positive testing Nonfunctional testing Regression testing z = = H Error guessing 
ЖЫ Based оп tester’s experience, scenarios, 
checklists 
— Negative testing Re-testing — Heuristic evaluation 
Exploratory 
L— Acceptance testing 4] Error seeding 
i—i Operational testing By intrusion to application work process 
Sis нан | —] Mutation testing 
ИТ И т А Ву automation Р И R т 
Usability testing Reliability testing techniques Intrusive testing Nonintrusive testing 
- Ву operational environment 
Accessibility testing Recoverability testing Ш 
Ву input data selection techniques 
-~ H Development testing 
Interface testing Failover testing УО 
Equivalence partitioning мена в 
Data quality testing апа Веһаміог-агі релизе 
В р uality testi ehavior-driven 
Security testing Database integrity testing testing 
Boundary value analysis 
Internationalization testing Resource utilization testing By application behavior (models) 











Domain testing 














By code structures 








Localization testing 





4] Decision table testing 











Performance testing Pairwise testing 


Statement 
testing 

















State transition testing 





Load testing 


Compatibility testing (Capacity testing) 

















Orthogonal array testing 
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Configuration ~ Specification-based testing 


Г | testing Scalability testing 






































Condition testing By code 











Г Model-based testing 














Grose browsen Volume testing 
testing Multiple 


condition testing 








Control flow testing 








— Use case testing 
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Comparison testing Decision testing Data flow testing 
— Parallel testing 
Concurrency testing Modified 
Qualification testing condition State transition testing 








decision testing p= Random testing 





















































































































































































Exh: sting Path testing Code review 
—] А / В testing 
—] Ву chronology 
General chronology By component hierarchy By attention to requirements and requirements’ components 
Bottom-up Top-down y Hybrid Момипайюпа! 
к Медайуе testin testin i testini i ое 
и Negative ositive complex) 8 ы кылы ы ыры ti components testing 
Positive (simple) (complex) = Requirements components testing 
(simple) ра 5 testing 
General typical scenarios 
Typical scenario 1 Typical scenario 2 Typical scenario 3 





































Integration. 
testing 


Critical path в 
testing 






і Gamma testing 


System testing 







ашышын Beta testin 
Smoke testing i 





Unit testing Alpha testing 





“нума | ) О Acceptance testing 
testing 


Рисунок 2.3.c — Подробная классификация тестирования (англоязычный вариант) 
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2.3.2.2. Классификация по запуску кода на исполнение 


Далеко не всякое тестирование предполагает взаимодействие с работаю- 


щим приложением. Потому в рамках данной классификации выделяют: 


Статическое тестирование (static testing!) — тестирование без запуска 
кода на исполнение. В рамках этого подхода тестированию могут подвер- 
гаться: 

о Документы (требования, тест-кейсы, описания архитектуры приложе- 
ния, схемы баз данных и т.д.). 

о Графические прототипы (например, эскизы пользовательского интер- 
фейса). 

о Код приложения (что часто выполняется самими программистами в 
рамках аудита кода (code геуіем''), являющегося специфической Ba- 
риацией взаимного просмотра“ в применении к исходному коду). Код 
приложения также можно проверять с использованием техник тести- 
рования на основе структур кода“. 

о Параметры (настройки) среды исполнения приложения. 

о Подготовленные тестовые данные. 


Динамическое тестирование (dynamic testing!) — тестирование с запуском 
кода на исполнение. Запускаться на исполнение может как код всего прило- 
жения целиком (системное тестирование), так и код нескольких взаимосвя- 
занных частей (интеграционное тестирование“), отдельных частей (модуль- 
ное или компонентное тестирование?!) и даже отдельные участки кода. Oc- 
новная идея этого вида тестирования состоит в том, что проверяется реаль- 
ное поведение (части) приложения. 


2.3.2.3. Классификация по доступу к коду и архитектуре приложения 


Метод белого ящика (white бох їеѕііпо'', open box testing, clear рох testing, 
glass box testing) — у тестировщика есть доступ к внутренней структуре и коду 
приложения, а также есть достаточно знаний для понимания увиденного. Вы- 
деляют даже сопутствующую тестированию по методу белого ящика гло- 
бальную технику — тестирование на основе дизайна (design-based testing’). 
Для более глубокого изучения сути метода белого ящика рекомендуется 
ознакомиться с техниками исследования потока управления? или потока 
данных3, использования диаграмм состояний. Некоторые авторы склонны 
жёстко связывать этот метод со статическим тестированием, но ничто не ме- 
шает тестировщику запустить код на выполнение и при этом периодически 
обращаться к самому коду (а модульное тестирование?“ и вовсе предпола- 
гает запуск кода на исполнение и при этом работу именно с кодом, а не с 
«приложением целиком»). 





115 Static testing. Testing of a software development artifact, e.g., requirements, design ог code, without execution о these artifacts, 
e.g., reviews or static analysis. [ISTQB Glossary] 

116 Jason Cohen, «Best Kept Secrets of Peer Code Review (Modern Approach. Practical Advice.)». Официально распространяе- 
мую электронную версию книги можно взять здесь: https://static1.smartbear.co/smartbear/media/pdfs/best-kept-secrets-of- 
реег-соае-геміем_геаігесіеа.раѓ 


117 Dynamic testing. Testing that involves {Не execution of the software ої а component ог system. [ISTQB Glossary] 
118 White box testing. Testing based on an analysis of the internal structure of the component or system. [ISTQB Glossary] 


119 Design-based Testing. An approach to testing in which test cases are designed based on the architecture and/or detailed design 
of a component or system (e.g. tests of interfaces between components or systems). [ISTQB Glossary] 
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e Метод чёрного ящика (black бох testing, closed бох testing, specification- 
based testing) — у тестировщика либо нет доступа к внутренней структуре и 
коду приложения, либо недостаточно знаний для их понимания, либо он со- 
знательно не обращается к ним в процессе тестирования. При этом абсолют- 
ное большинство перечисленных на рисунках 2.3.5 и 2.3.с видов тестирова- 
ния работают по методу чёрного ящика, идею которого в альтернативном 
определении можно сформулировать так: тестировщик оказывает на прило- 
жение воздействия (и проверяет реакцию) тем же способом, каким при ре- 
альной эксплуатации приложения на него воздействовали бы пользователи 
или другие приложения. В рамках тестирования по методу чёрного ящика ос- 
новной информацией для создания тест-кейсов выступает документация 
(особенно — требования (гедиігетепіѕ-раѕеа {ез1тд'2')) и общий здравый 
смысл (для случаев, когда поведение приложения в некоторой ситуации не 
регламентировано явно; иногда это называют «тестированием на основе не- 
явных требований», но канонического определения у этого подхода нет). 


e Метод серого ящика (gray бох testing!?) — комбинация методов белого 
ящика и чёрного ящика, состоящая в том, что к части кода и архитектуры у 
тестировщика доступ есть, а к части — нет. На рисунках 2.3.6 и 2.3.с этот 
метод обозначен особым пунктиром и серым цветом потому, что его явное 
упоминание — крайне редкий случай: обычно говорят о методах белого или 
чёрного ящика в применении к тем или иным частям приложения, при этом 
понимая, что «приложение целиком» тестируется по методу серого ящика. 





| Y ‘Важно! Некоторые авторы! определяют метод серого ящика как 
‚ противопоставление методам белого и чёрного ящика, особо под- | 
‚ чёркивая, что при работе по методу серого ящика внутренняя струк- ' 
‚ тура тестируемого объекта известна частично и выясняется по мере 
исследования. Этот подход, бесспорно, имеет право на существо- ' 
‚ вание, но в своём предельном случае он вырождается до состояния _ 
«часть системы мы знаем, часть — не знаем», т.е. до всё той же. 





Если сравнить основные преимущества и недостатки перечисленных мето- 
дов, получается следующая картина (см. таблицу 2.3.а). 

Методы белого и чёрного ящика не являются конкурирующими или взаимо- 
исключающими — напротив, они гармонично дополняют друг друга, компенсируя 
таким образом имеющиеся недостатки. 





120 Black box testing. Testing, either functional ог non-functional, without reference to {ће internal structure of the component ог 
system. [ISTQB Glossary] 

121 Requirements-based Testing. An approach to testing іп which test cases аге designed based оп test objectives апа test condi- 
tions derived from requirements, e.g. tests that exercise specific functions or probe non-functional attributes such as reliability or 
usability. [ISTQB Glossary] 

122 Gray box testing is a software testing method, which is a combination of Black Box Testing method and White Box Testing 
method. ... In Gray Box Testing, the internal structure is partially known. This involves having access to internal data structures 
and algorithms for purposes of designing the test cases, but testing at the user, or black-box level. [«Gray Box Testing Funda- 
mentals», http:/softwaretestingfundamentals.com/gray-box-testing]. 

123 «Gray box testing (gray box) definition», Margaret Rouse [http://searchsoftwarequality.techtarget.com/definition/gray-box] 
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Таблица 2.3.а — Преимущества и недостатки методов белого, чёрного и серого 


ящиков 





Преимущества 


Недостатки 





Метод белого 
ящика 


Показывает скрытые проблемы и 
упрощает их диагностику. 
Допускает достаточно простую ав- 
томатизацию тест-кейсов и их вы- 
полнение на самых ранних ста- 
диях развития проекта. 

Обладает развитой системой мет- 
рик, сбор и анализ которых легко 
автоматизируется. 

Стимулирует разработчиков к 
написанию качественного кода. 
Многие техники этого метода яв- 
ляются проверенными, хорошо 
себя зарекомендовавшими реше- 
ниями, базирующимися на строгом 
техническом подходе. 


• Не может выполняться тестиров- 
щиками, не обладающими доста- 
точными знаниями в области про- 
граммирования. 

• Тестирование сфокусировано на 
реализованной функционально- 
сти, что повышает вероятность 
пропуска нереализованных требо- 
ваний. 

• Поведение приложения исследу- 
ется в отрыве от реальной среды 
выполнения и не учитывает её 
влияние. 

• Поведение приложения исследу- 
ется в отрыве от реальных поль- 
зовательских сценариев! 3). 





Метод чёрного 
ящика 


Тестировщик не обязан обладать 
(глубокими) знаниями в области 
программирования. 

Поведение приложения исследу- 
ется в контексте реальной среды 
выполнения и учитывает её влия- 
ние. 

Поведение приложения исследу- 
ется в контексте реальных пользо- 
вательских сценариев!'3!. 
Тест-кейсы можно создавать уже 
на стадии появления стабильных 
требований. 

Процесс создания тест-кейсов поз- 
воляет выявить дефекты в требо- 
ваниях. 

Допускает создание тест-кейсов, 
которые можно многократно ис- 
пользовать на разных проектах. 





• Возможно повторение части тест- 
кейсов, уже выполненных разра- 
ботчиками. 

• Высока вероятность того, что 
часть возможных вариантов пове- 
дения приложения останется не- 
протестированной. 

• Для разработки высокоэффектив- 
ных тест-кейсов необходима каче- 
ственная документация. 

• Диагностика обнаруженных де- 
фектов более сложна в сравнении 
с техниками метода белого ящика. 

• В связи с широким выбором тех- 
ник и подходов затрудняется пла- 
нирование и оценка трудозатрат. 

e В случае автоматизации могут NO- 
требоваться сложные дорогостоя- 
щие инструментальные средства. 





Метод серого 
ящика 








Сочетает преимущества и недостатки методов белого и чёрного ящика. 





2.3.2.4. Классификация по степени автоматизации 


e Ручное тестирование (manual testing) — тестирование, в котором тест- 
кейсы выполняются человеком вручную без использования средств автома- 
тизации. Несмотря на то что это звучит очень просто, от тестировщика в те 
или иные моменты времени требуются такие качества, как терпеливость, 
наблюдательность, креативность, умение ставить нестандартные экспери- 
менты, а также умение видеть и понимать, что происходит «внутри системы», 
т.е. как внешние воздействия на приложение трансформируются в его внут- 
ренние процессы. 





124 Manual testing is performed Бу the tester who carries out all the actions оп {һе tested application manually, step Бу step апа 


indicates whether a particular step was accomplished successfully or whether it failed. Manual testing is always a part of any 
testing effort. It is especially useful in the initial phase of software development, when the software and its user interface are not 
stable enough, and beginning the automation does not make sense. (SmartBear TestComplete user manual, https://sup- 


port.smartbear.com/testcomplete/docs/testing-with/deprecated/manual/index.html) 
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e Автоматизированное тестирование (automated testing, test ащотаНоп'2) — 
набор техник, подходов и инструментальных средств, позволяющий исклю- 
чить человека из выполнения некоторых задач в процессе тестирования. 
Тест-кейсы частично или полностью выполняет специальное инструменталь- 
ное средство, однако разработка тест-кейсов, подготовка данных, оценка ре- 
зультатов выполнения, написания отчётов об обнаруженных дефектах — всё 
это и многое другое по-прежнему делает человек. 





_ Некоторые авторы"! говорят отдельно о «полуавтоматизирован- 
ном» тестировании как варианте ручного с частичным использова- 
нием средств автоматизации и отдельно об «автоматизированном» | 
‚ тестировании (относя туда области тестирования, в которых компь- 
_ ютер выполняет ощутимо большой процент задач). Но т.к. без yya- 
‚ стия человека всё равно не обходится ни один из этих видов тести- ' 
‚ рования, не станем усложнять набор терминов и ограничимся одним _ 





понятием «автоматизированное тестирование». 








У автоматизированного тестирования есть много как сильных, так и слабых 
сторон (см. таблицу 2.3.0). 


Таблица 2.3.6 — Преимущества и недостатки автоматизированного тестирования 





Недостатки 
• Необходим высококвалифицированный пер- 
сонал в силу того факта, что автоматизация 
— это «проект внутри проекта» (со своими 


Преимущества 
® Скорость выполнения тест-кейсов может в 
разы и на порядки превосходить возможно- 
сти человека. 








® Отсутствие влияния человеческого фактора 
в процессе выполнения тест-кейсов (устало- 
сти, невнимательности и т.д.). 

® Минимизация затрат при многократном вы- 
полнении тест-кейсов (участие человека 
здесь требуется лишь эпизодически). 

• Способность средств автоматизации выпол- 
нить тест-кейсы, в принципе непосильные 
для человека в силу своей сложности, скоро- 
сти или иных факторов. 

• Способность средств автоматизации соби- 
рать, сохранять, анализировать, агрегиро- 
вать и представлять в удобной для восприя- 
тия человеком форме колоссальные объёмы 
данных. 

® Способность средств автоматизации выпол- 
нять низкоуровневые действия с приложе- 
нием, операционной системой, каналами пе- 
редачи данных ит.д. 





требованиями, планами, кодом ит.д.) 
Высокие затраты на сложные средства авто- 
матизации, разработку и сопровождение 
кода тест-кейсов. 

Автоматизация требует более тщательного 
планирования и управления рисками, т.к. в 
противном случае проекту может быть нане- 
сён серьёзный ущерб. 

Средств автоматизации крайне много, что 
усложняет проблему выбора того или иного 
средства и может повлечь за собой финансо- 
вые затраты (и риски), необходимость обуче- 
ния персонала (или поиска специалистов). 

В случае ощутимого изменения требований, 
смены технологического домена, перера- 
ботки интерфейсов (как пользовательских, 
так и программных) многие тест-кейсы стано- 
вятся безнадёжно устаревшими и требуют 
создания заново. 








Если же выразить все преимущества и недостатки автоматизации тестиро- 
вания одной фразой, то получается, что автоматизация позволяет ощутимо увели- 
чить тестовое покрытие (test соуегаде!®), но при этом столь же ощутимо увеличи- 
вает риски. 





125 Test automation is the use of software їо control {Не execution of tests, the comparison of actual outcomes to predicted outcomes, 
the setting up of test preconditions, and other test control and test reporting functions. Commonly, test automation involves 
automating a manual process already in place that uses a formalized testing process. (Ravinder Veer Hooda, “An Automation of 
Software Testing: A Foundation for the Future”) 

126 Coverage, Test coverage. The degree, expressed as a percentage, to which a specified coverage item has been exercised by a 
test suite. [ISTQB Glossary] 
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© Задание 2.3.а: сформируйте аналогичную таблицу с преимуществами и | 
‚ недостатками ручного тестирования. Подсказка: здесь недостаточно про- | 
‚ сто поменять заголовки колонок с преимуществами и недостатками авто- | 
‹ матизации. | 








2.3.2.5. Классификация по уровню детализации приложения (по уровню 
тестирования) 





Внимание! Возможна путаница, вызванная тем, что единого общеприня- | 
‚ того набора классификаций не существует, и две из них имеют очень схо- | 
‚ жие названия: 
| e «По уровню детализации приложения» = «по уровню тестирования». | 
e «По (убыванию) степени важности тестируемых функций» = «по. 








• Модульное (компонентное) тестирование (unit testing, module testing, com- 
ponent testing'?7) направлено на проверку отдельных небольших частей npn- 
ложения, которые (как правило) можно исследовать изолированно от других 
подобных частей. При выполнении данного тестирования могут проверяться 
отдельные функции или методы классов, сами классы, взаимодействие клас- 
сов, небольшие библиотеки, отдельные части приложения. Часто данный 
вид тестирования реализуется с использованием специальных технологий и 
инструментальных средств автоматизации тестирования", значительно 
упрощающих и ускоряющих разработку соответствующих тест-кейсов. 





| Из-за особенностей перевода на русский язык теряются нюансы | 


степени детализации: «юнит-тестирование», как правило, направ- , 
‚ лено на тестирование атомарных участков кода, «модульное» — на 
тестирование классов и небольших библиотек, «компонентное» — 
на тестирование библиотек и структурных частей приложения. Но 
эта классификация не стандартизирована, и у различных авторов ' 
‚можно встретить совершенно разные взаимоисключающие трак- | 
товки. 





e Интеграционное тестирование (integration testing’, component integration 
testing'?2, pairwise integration testing!®, system integration testingt3t, incremental 
testing'?2, interface testing'33, thread testing!) направлено на проверку взаимо- 
действия между несколькими частями приложения (каждая из которых, в 
свою очередь, проверена отдельно на стадии модульного тестирования). К 
сожалению, даже если мы работаем с очень качественными отдельными 





127 Module testing, Unit testing, Component testing. Тһе testing оѓ individual software components. [ISTQB Glossary] 

128 Integration testing. Testing performed to expose defects in the interfaces and in the interactions between integrated components 
or systems. [ISTQB Glossary] 

129 Component integration testing. Testing performed to expose defects in the interfaces and interaction between integrated com- 
ponents. [ISTQB Glossary] 

130 Pairwise integration testing. A form of integration testing that targets pairs of components that work together, as shown in a call 
graph. [ISTQB Glossary] 

131 System integration testing. Testing the integration of systems and packages; testing interfaces to external organizations (e.g. 
Electronic Data Interchange, Internet). [ISTQB Glossary] 

132 Incremental testing. Testing where components or systems are integrated and tested one or some at a time, until all the compo- 
nents or systems are integrated and tested. [ISTQB Glossary] 

133 Interface testing. An integration test type that is concerned with testing the interfaces between components or systems. [ISTQB 
Glossary] 

134 Thread testing. An approach to component integration testing where the progressive integration of components follows the im- 
plementation of subsets of the requirements, as opposed to the integration of components by levels of a hierarchy. [ISTQB 
Glossary] 
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компонентами, «на стыке» их взаимодействия часто возникают проблемы. 
Именно эти проблемы и выявляет интеграционное тестирование. (См. также 
техники восходящего, нисходящего и гибридного тестирования в хронологи- 
ческой классификации по иерархии компонентов.) 


e Системное тестирование (system testing!) направлено на проверку всего 
приложения как единого целого, собранного из частей, проверенных на двух 
предыдущих стадиях. Здесь не только выявляются дефекты «на стыках» 
компонентов, но и появляется возможность полноценно взаимодействовать 
с приложением с точки зрения конечного пользователя, применяя множество 
других видов тестирования, перечисленных в данной главе. 


С классификацией по уровню детализации приложения связан интересный 
печальный факт: если предыдущая стадия обнаружила проблемы, то на следую- 
щей стадии эти проблемы точно нанесут удар по качеству; если же предыдущая 
стадия не обнаружила проблем, это ещё никоим образом не защищает нас от про- 
блем на следующей стадии. 

Для лучшего запоминания степень детализации в модульном, интеграцион- 
ном и системном тестировании показана схематично на рисунке 2.3.4. 

Системное | | 
НИЯ 





Интеграционное : 
тестирование : 















































чины нөн 
О. 
Рисунок 2.3.4 — Схематичное представление классификации тестирования по 
уровню детализации приложения 








Если обратиться к словарю ISTQB и прочитать определение уровня тестиро- 
вания (test Іеме!"з), то можно увидеть, что аналогичное разбиение на модульное, 
интеграционное и системное тестирование, к которым добавлено ещё и приёмоч- 
ное тестирование, используется в контексте разделения областей ответственно- 
сти на проекте. Но такая классификация больше относится к вопросам управления 
проектом, чем к тестированию в чистом виде, а потому выходит за рамки рассмат- 
риваемых нами вопросов. 





‚ Самый полный вариант классификации тестирования по уровню тестиро- | 
‚ вания можно посмотреть в статье «What аге Software Testing Геме!ѕ?'27». 
Для улучшения запоминания отразим эту идею на рисунке 2.3.6, но отме- | 








135 System testing. Тһе process о testing ап integrated system to verify that it meets specified requirements. [ISTQB Glossary] 

136 Test level. A group of test activities that are organized and managed together. A test level is linked to the responsibilities in a 
project. Examples of test levels are component test, integration test, system test and acceptance test. [ISTQB Glossary] 

137 «What are Software Testing Levels?» [http://istqbexamcertification.com/what-are-software-testing-levels/] 
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Гамма-тестирование 
Бета-тестирование 
Альфа-тестирование 
Приёмочное тестирование 
Системное тестирование 
Системное интеграционное 
тестирование 
Компонентное интеграционное 
тестирование 
Интеграционное тестирование 
Компонентное тестирование 
Модульное тестирование 


| Рисунок 2.3.е — Самый полный вариант классификации тестирования по | 








Уровень тестирования 





2.3.2.6. Классификация по (убыванию) степени важности тестируемых 
функций (по уровню функционального тестирования) 


В некоторых источниках эту разновидность классификации также называют 
«по глубине тестирования». 





Внимание! Возможна путаница, вызванная тем, что единого общеприня- 
‚ того набора классификаций не существует, и две из них имеют очень схо- | 
| жие названия: | 
| e «По уровню детализации приложения» = «по уровню тестирования». | 
e «По (убыванию) степени важности тестируемых функций» = «по. 


уровню функционального тестирования». 








e Дымовое тестирование (smoke test'3, intake test'3, build verification testo) 
направлено на проверку самой главной, самой важной, самой ключевой 
функциональности, неработоспособность которой делает бессмысленной 





138 Smoke test, Confidence test, Sanity test. А subset of а! Чейпед/р!аппеч test cases that cover the тат functionality of а 
component or system, to ascertaining that the most crucial functions of a program work, but not bothering with finer details. 
[ISTQB Glossary] 

139 Intake test. A special instance of a smoke test to decide if the component or system is ready for detailed and further testing. An 
intake test is typically carried out at the start of the test execution phase. [ISTQB Glossary] 

140 Build verification test. A set of automated tests which validates the integrity of each new build and verifies its key/core function- 
ality, stability and testability. It is an industry practice when a high frequency of build releases occurs (e.g., agile projects) and it 
is run on every new build before the build is released for further testing. [ISTQB Glossary] 
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саму идею использования приложения (или иного объекта, подвергаемого 
дымовому тестированию). 





9 Внимание! Очень распространённая проблема! Из-за особенности | 
| перевода на русский язык под термином «приёмочное тестирова- | 
| ние» часто может пониматься как «smoke їеѕі»?®, так и «acceptance 
_1езї»®#, которые изначально не имеют между собою ничего общего. , 
' Возможно, в том числе поэтому многие тестировщики почти не nC- 
‚ пользуют русский перевод «дымовое тестирование», а так и TOBO- , 





Дымовое тестирование проводится после выхода нового билда, чтобы опре- 
делить общий уровень качества приложения и принять решение о (не)целе- 
сообразности выполнения тестирования критического пути и расширенного 
тестирования. Поскольку тест-кейсов на уровне дымового тестирования от- 
носительно немного, а сами они достаточно просты, но при этом очень часто 
повторяются, они являются хорошими кандидатами на автоматизацию. В 
связи с высокой важностью тест-кейсов на данном уровне пороговое значе- 
ние метрики их прохождения часто выставляется равным 100 % или близким 
к 100 %. 


Очень часто можно услышать вопрос о том, чем «smoke test» отличается от 
«sanity test». В глоссарии ISTQB сказано просто: «sanity test: Зее smoke test». 
Но некоторые авторы утверждают"“", что разница" есть и может быть выра- 
жена следующей схемой (рисунок 2.3.1}: 







Начальные, 
относительно 
нестабильные 

билды 


Smoke Test 


Дальнейшее 
тестирование 





Рисунок 2.3.1 — Трактовка разницы между smoke test и sanity test 


Близкие к 
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Sanity Test 


Тестирование критического пути (critical ра!" test) направлено Ha иссле- 
дование функциональности, используемой типичными пользователями в ти- 
пичной повседневной деятельности. Как видно из определения в сноске кан- 
глоязычной версии термина, сама идея позаимствована из управления про- 
ектами и трансформирована в контексте тестирования в следующую: суще- 
ствует большинство пользователей, которые чаще всего используют некое 





141 
142 


«Smoke Vs Sanity Testing — Introduction апа Differences» [http:/www.guru99.com/smoke-sanity-testing.html] 
«Smoke testing and sanity testing — Quick and simple differences» [http:/www.softwaretestinghelp.com/smoke-testing-and-san- 


ity-testing-difference/] 

143 Critical path. Longest sequence of activities in a project plan which must be completed on time for the project to complete on due 
date. An activity on the critical path cannot be started until its predecessor activity is complete; if it is delayed for a day, the entire 
project will be delayed for а day unless the activity following the delayed activity is completed а day earlier. [httpọs://ever- 
hour.com/blog/how-to-calculate-critical-path/] 
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подмножество функций приложения (см. рисунок 2.3.4). Именно эти функции 
и нужно проверить, как только мы убедились, что приложение «в принципе 
работает» (дымовой тест прошёл успешно). Если по каким-то причинам при- 
ложение не выполняет эти функции или выполняет их некорректно, очень 
многие пользователи не смогут достичь множества своих целей. Пороговое 
значение метрики успешного прохождения «теста критического пути» уже не- 
много ниже, чем в дымовом тестировании, но всё равно достаточно высоко 
(как правило, порядка 70-80-90 % — в зависимости от сути проекта). 





Рисунок 2.3.0 — Суть тестирования критического пути 


e Расширенное тестирование (extended test) направлено на исследование 
всей заявленной в требованиях функциональности — даже той, которая 
низко проранжирована по степени важности. При этом здесь также учитыва- 
ется, какая функциональность является более важной, а какая — менее важ- 
ной. Но при наличии достаточного количества времени и иных ресурсов тест- 
кейсы этого уровня могут затронуть даже самые низкоприоритетные требо- 
вания. 


Ещё одним направлением исследования в рамках данного тестирования яв- 
ляются нетипичные, маловероятные, экзотические случаи и сценарии ис- 
пользования функций и свойств приложения, затронутых на предыдущих 
уровнях. Пороговое значение метрики успешного прохождения расширен- 
ного тестирования существенно ниже, чем в тестировании критического пути 
(иногда можно увидеть даже значения в диапазоне 30-50 %, т.к. подавляю- 
щее большинство найденных здесь дефектов не представляет угрозы для 
успешного использования приложения большинством пользователей). 





К сожалению, часто можно встретить мнение, что дымовое тести- 
| ‚ рование, тестирование критического пути и расширенное тестиро- 
‚ вание напрямую связаны с позитивным” тестированием и негатив- ' 
ным? тестированием, и негативное появляется только на уровне 
‚ тестирования критического пути. Это не так. Как позитивные, так n 
негативные тесты могут (а иногда и обязаны) встречаться на всех | 
‚ перечисленных уровнях. Например, деление на ноль в калькуля- 
‚ торе явно должно относиться к дымовому тестированию, хотя это | 








144 Extended test. Тһе idea is to develop а comprehensive application system test suite Бу modeling essential capabilities аз ex- 
tended use cases. [By «Extended Use Case Test Design Pattern», Rob Kuijt] 
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Для лучшего запоминания отразим эту классификацию графически: 


Расширенное тестирование 









Тестирование критического 
пути 


тестирования 


Уровень функционального 


Дымовое тестирование 


Глубина детализации исследования 
приложения 
Последовательность выполнения 





Степень важности тестируемых функций 


Рисунок 2.3.һ — Классификация тестирования по (убыванию) степени важности 
тестируемых функций (по уровню функционального тестирования) 


2.3.2.7. Классификация по принципам работы с приложением 


• Позитивное тестирование (positive testing!) направлено на исследование 
приложения в ситуации, когда все действия выполняются строго по инструк- 
ции без каких бы то ни было ошибок, отклонений, ввода неверных данных и 
т.д. Если позитивные тест-кейсы завершаются ошибками, это тревожный 
признак — приложение работает неверно даже в идеальных условиях (и 
можно предположить, что в неидеальных условиях оно работает ещё хуже). 
Для ускорения тестирования несколько позитивных тест-кейсов можно объ- 
единять (например, перед отправкой заполнить все поля формы верными 
значениями) — иногда это может усложнить диагностику ошибки, но суще- 
ственная экономия времени компенсирует этот риск. 


e Негативное тестирование (negative їеѕііпо'*, invalid {езтд!“7) — направлено 
на исследование работы приложения в ситуациях, когда с ним выполняются 
(некорректные) операции и/или используются данные, потенциально приво- 
дящие к ошибкам (классика жанра — деление на ноль). Поскольку в реаль- 
ной жизни таких ситуаций значительно больше (пользователи допускают 
ошибки, злоумышленники осознанно «ломают» приложение, в среде работы 
приложения возникают проблемы и т.д.), негативных тест-кейсов оказыва- 
ется значительно больше, чем позитивных (иногда — в разы или даже на 
порядки). В отличие от позитивных негативные тест-кейсы не стоит объеди- 
нять, т.к. подобное решение может привести к неверной трактовке поведения 
приложения и пропуску (необнаружению) дефектов. 





145 Positive testing is testing process where the system validated against the valid input data. Іп this testing tester always check for 
only valid set of values and check if application behaves as expected with its expected inputs. The main intention of this testing 
is to check whether software application not showing error when not supposed to & showing error when supposed to. Such 
testing is to be carried out keeping positive point of view & only execute the positive scenario. Positive Testing always tries to 
prove that a given product and project always meets the requirements and specifications. [http://www.softwaretest- 
ingclass.com/positive-and-negative-testing-in-software-testing/] 

146 Negative testing. Tests aimed at showing that a component or system does not work. Negative testing is related to the testers’ 
attitude rather than a specific test approach or test design technique, e.g. testing with invalid input values or exceptions. [ISTQB 
Glossary] 

147 Invalid testing. Testing using input values that should be rejected by the component or system. [ISTQB Glossary] 
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2.3.2.8. Классификация по природе приложения 


Данный вид классификации является искусственным, поскольку «внутри» 
речь будет идти об одних и тех же видах тестирования, отличающихся в данном 
контексте лишь концентрацией на соответствующих функциях и особенностях при- 
ложения, использованием специфических инструментов и отдельных техник. 


e Тестирование веб-приложений (web-applications testing) сопряжено с ин- 
тенсивной деятельностью в области тестирования совместимости? (в OCO- 
бенности — кросс-браузерного тестирования??), тестирования производи- 
тельности, автоматизации тестирования с использованием широкого спек- 
тра инструментальных средств. 


e Тестирование мобильных приложений (mobile applications testing) также 
требует повышенного внимания к тестированию совместимости 8, оптимиза- 
ции производительности?? (в том числе клиентской части с точки зрения CHN- 
жения энергопотребления), автоматизации тестирования с применением 
эмуляторов мобильных устройств. 


e Тестирование настольных приложений (desktop applications testing) явля- 
ется самым классическим среди всех перечисленных в данной классифика- 
ции, и его особенности зависят от предметной области приложения, нюансов 
архитектуры, ключевых показателей качества и т.д. 


Эту классификацию можно продолжать очень долго. Например, можно от- 
дельно рассматривать тестирование консольных приложений (console appli- 
cations testing) и приложений с графическим интерфейсом (GUl-applications 
testing), серверных приложений (server applications testing) и клиентских Npn- 
ложений (client applications testing) n т.д. 


2.3.2.9. Классификация по фокусировке на уровне архитектуры приложе- 
ния 


Данный вид классификации, как и предыдущий, также является искусствен- 
ным и отражает лишь концентрацию внимания на отдельной части приложения. 


e Тестирование уровня представления (presentation tier testing) сконцентри- 
ровано на той части приложения, которая отвечает за взаимодействие с 
«внешним миром» (как пользователями, так и другими приложениями). Здесь 
исследуются вопросы удобства использования, скорости отклика интер- 
фейса, совместимости с браузерами, корректности работы интерфейсов. 


e Тестирование уровня бизнес-логики (business logic tier testing) отвечает за 
проверку основного набора функций приложения и строится на базе ключе- 
вых требований к приложению, бизнес-правил и общей проверки функцио- 
нальности. 


e Тестирование уровня данных (data tier testing) сконцентрировано на той 
части приложения, которая отвечает за хранение и некоторую обработку дан- 
ных (чаще всего — в базе данных или ином хранилище). Здесь особый инте- 
рес представляет тестирование данных, проверка соблюдения бизнес-пра- 
вил, тестирование производительности. 


Если вы не знакомы с понятием многоуровневой архитектуры приложе- | 
“ний, ознакомьтесь с ним хотя бы по материалу" из Википедии. , 















148 «Миншег architecture», Wikipedia [http://en.wikipedia.org/wiki/Multitier_architecture] 
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2.3.2.10. Классификация по привлечению конечных пользователей 


Все три перечисленных ниже вида тестирования относятся к операционному 
тестированию". 


e Альфа-тестирование (alpha testing'4) выполняется внутри организации-раз- 
работчика с возможным частичным привлечением конечных пользователей. 
Может являться формой внутреннего приёмочного тестирования?*. В Heko- 
торых источниках отмечается, что это тестирование должно проводиться без 
привлечения команды разработчиков, но другие источники не выдвигают та- 
кого требования. Суть этого вида вкратце: продукт уже можно периодически 
показывать внешним пользователям, но он ещё достаточно «сырой», потому 
основное тестирование выполняется организацией-разработчиком. 


e Бета-тестирование (beta їеѕііпд') выполняется вне организации-разработ- 
чика с активным привлечением конечных пользователей/заказчиков. Может 
являться формой внешнего приёмочного тестирования. Суть этого вида 
вкратце: продукт уже можно открыто показывать внешним пользователям, он 
уже достаточно стабилен, но проблемы всё ещё могут быть, и для их выяв- 
ления нужна обратная связь от реальных пользователей. 


e Гамма-тестирование (датта їеѕііпо'') — финальная стадия тестирования 
перед выпуском продукта, направленная на исправление незначительных 
дефектов, обнаруженных в бета-тестировании. Как правило, также выполня- 
ется с максимальным привлечением конечных пользователей/заказчиков. 
Может являться формой внешнего приёмочного тестирования. Суть этого 
вида вкратце: продукт уже почти готов, и сейчас обратная связь от реальных 
пользователей используется для устранения последних недоработок. 


2.3.2.11. Классификация по степени формализации 


e Тестирование на основе тест-кейсов (scripted testing’, test case based test- 
ing) — формализованный подход, в котором тестирование производится на 
основе заранее подготовленных тест-кейсов, наборов тест-кейсов и иной до- 
кументации. Это самый распространённый способ тестирования, который 
также позволяет достичь максимальной полноты исследования приложения 
за счёт строгой систематизации процесса, удобства применения метрик и 
широкого набора выработанных за десятилетия и проверенных на практике 
рекомендаций. 





149 Alpha testing. Simulated ог actual operational testing by potential иѕегѕ/сиѕіотегѕ ог ап independent test team а the developers’ 
site, but outside the development organization. Alpha testing is often employed for off-the-shelf software as a form of internal 
acceptance testing. [ISTQB Glossary] 

150 Beta testing. Operational testing by potential and/or existing users/customers at an external site not otherwise involved with the 
developers, to determine whether or not a component or system satisfies the user/customer needs and fits within the business 
processes. Beta testing is often employed as a form of external acceptance testing for off-the-shelf software in order to acquire 
feedback from the market. [ISTQB Glossary] 

151 Gamma testing is done when software is ready for release with specified requirements, this testing done directly by skipping all 
the in-house testing activities. The software is almost ready for final release. No feature development or enhancement of the 
software is undertaken and tightly scoped bug fixes are the only code. Gamma check is performed when the application is ready 
for release to the specified requirements and this check is performed directly without going through all the testing activities at 
home. [http:/www.360logica.com/blog/2012/06/what-are-alpha-beta-and-gamma-testing.html] 

152 Scripted testing. Test execution carried out by following a previously documented sequence of tests. [ISTQB Glossary] 
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e Исследовательское тестирование (exploratory їеѕїіпд'з) — частично фор- 
мализованный подход, в рамках которого тестировщик выполняет работу с 
приложением по выбранному сценарию"“з, который, в свою очередь, gopa- 
батывается в процессе выполнения с целью более полного исследования 
приложения. Ключевым фактором успеха при выполнении исследователь- 
ского тестирования является именно работа по сценарию, а не выполнение 
разрозненных бездумных операций. Существует даже специальный сценар- 
ный подход, называемый сессионным тестированием (5еѕѕіоп-раѕеа test- 
іп9'%). В качестве альтернативы сценариям при выборе действий с приложе- 
нием иногда могут использоваться чек-листы, и тогда этот вид тестирования 
называют тестированием на основе чек-листов (сһескііѕі-раѕеа testingt55). 










‚ Дополнительную информацию об исследовательском тестирова- 
нии можно получить из статьи Джеймса Баха «Что такое исследо- 
ательское тестирование?» 





e Свободное (интуитивное) тестирование (аа Пос їеѕїіпо"7) — полностью HE- 
формализованный подход, в котором не предполагается использования ни 
тест-кейсов, ни чек-листов, ни сценариев — тестировщик полностью опира- 
ется на свой профессионализм и интуицию (experience-based testing!) для 
спонтанного выполнения с приложением действий, которые, как он считает, 
могут обнаружить ошибку. Этот вид тестирования используется редко и ис- 
ключительно как дополнение к полностью или частично формализованному 
тестированию в случаях, когда для исследования некоторого аспекта пове- 
дения приложения (пока?) нет тест-кейсов. 





Ни в коем случае не стоит путать исследовательское и свободное _ 


| | тестирование. Это разные техники исследования приложения с раз- 
| ной степенью формализации, разными задачами и областями npn- 





2.3.2.12. Классификация по целям и задачам 
• Позитивное тестирование (рассмотрено ранее?°)). 
e Негативное тестирование (рассмотрено ранее?°). 


e Функциональное тестирование (functional testing?) — вид тестирования, 
направленный на проверку корректности работы функциональности прило- 
жения (корректность реализации функциональных требований). Часто 
функциональное тестирование ассоциируют с тестированием по методу чёр- 
ного ящика", однако и по методу белого ящика? вполне можно проверять 
корректность реализации функциональности. 





153 Exploratory testing. Ап informal test design technique where the tester actively controls the design of the tests аз those tests 
are performed and uses information gained while testing to design new and better tests. [ISTQB Glossary] 

154 Session-based Testing. An approach to testing in which test activities are planned as uninterrupted sessions of test design and 
execution, often used in conjunction with exploratory testing. [ISTQB Glossary] 

155 Checklist-based Testing. An experience-based test design technique whereby the experienced tester uses a high-level list of 
items to be noted, checked, or remembered, or a set of rules or criteria against which a product has to be verified. [ISTQB 
Glossary] 

156 «What is Exploratory Testing?», James Bach [http://www.satisfice.com/articles/what_is_et.shtml] 

157 Ad hoc testing. Testing carried out informally; no formal test preparation takes place, no recognized test design technique is 
used, there are no expectations for results and arbitrariness guides the test execution activity. [ISTQB Glossary] 

158 Experience-based Testing. Testing based on the tester’s experience, knowledge and intuition. [ISTQB Glossary] 

159 Functional testing. Testing based on an analysis of the specification of the functionality of a component or system. [ISTQB 
Glossary] 
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‚ Часто возникает вопрос, в чём разница между функциональным TE- 
‚ стированием (functional їеѕїіпо"%) и тестированием функционально- | 
сти (functionality testingt®). Подробнее о функциональном тестиро- 
вании можно прочесть в статье «What is Functional testing (Testing | 
оѓ functions) іп зоНмаге?»11, а о тестировании функциональности в 
‚ статье «What is functionality testing іп ѕоймаге?»те2. | 
‚ Если вкратце, то: | 
e функциональное тестирование (как антоним нефункциональ- , 
ного) направлено на проверку того, какие функции приложения | 
’ реализованы, и что они работают верным образом; 
e тестирование функциональности направлено на те же задачи, но ' 
| акцент смещён в сторону исследования приложения в реальной 





Нефункциональное тестирование (non-functional їеѕііпо'з) — вид тестиро- 
вания, направленный на проверку нефункциональных особенностей прило- 
жения (корректность реализации нефункциональных требований), таких 
как удобство использования, совместимость, производительность, безопас- 
НОСТЬ И Т.Д. 


Инсталляционное тестирование (installation testing, installability Тесїїпдї®ї) — 
тестирование, направленное на выявление дефектов, влияющих на протека- 
ние стадии инсталляции (установки) приложения. В общем случае такое те- 
стирование проверяет множество сценариев и аспектов работы инсталля- 
тора в таких ситуациях, как: 
о новая среда исполнения, в которой приложение ранее не было инстал- 
лировано; 
о обновление существующей версии («апгрейд»); 
изменение текущей версии на более старую («даунгрейд»); 
о повторная установка приложения с целью устранения возникших про- 
блем («переинсталляция»); 
о повторный запуск инсталляции после ошибки, приведшей к невозмож- 
ности продолжения инсталляции; 
о удаление приложения; 
установка нового приложения из семейства приложений; 
о автоматическая инсталляция без участия пользователя. 


О 


О 





160 Functionality testing. Тһе process ої testing to determine the functionality of а software product (ће capability of the software 
product to provide functions which meet stated and implied needs when the software is used under specified conditions). [ISTQB 
Glossary] 

161 «What is Functional testing (Testing of functions) in software?» [http://istqbexamcertification.com/what-is-functional-testing-test- 
ing-of-functions-in-software/] 


162 


«What is functionality testing in software?» [http://istqbexamcertification.com/what-is-functionality-testing-in-software/] 


163 Non-functional testing. Testing the attributes of a component or system that do not relate to functionality, e.g. reliability, efficiency, 
usability, maintainability and portability. [ISTQB Glossary] 

164 Installability testing. The process of testing the installability of a software product. Installability is the capability of the software 
product to be installed in a specified environment. [ISTQB Glossary] 
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e Регрессионное тестирование (regression testing!) — тестирование, 
направленное на проверку того факта, что в ранее работоспособной функци- 
ональности не появились ошибки, вызванные изменениями в приложении 
или среде его функционирования. Фредерик Брукс в своей книге «Мифиче- 
ский человеко-месяц»' писал: «Фундаментальная проблема при сопровож- 
дении программ состоит в том, что исправление одной ошибки с большой 
вероятностью (20—50 %) влечёт появление новой». Потому регрессионное 
тестирование является неотъемлемым инструментом обеспечения качества 
и активно используется практически в любом проекте. 


e Повторное тестирование (ге-їеѕїіпо', confirmation testing) — выполнение 
тест-кейсов, которые ранее обнаружили дефекты, с целью подтверждения 
устранения дефектов. Фактически этот вид тестирования сводится к дей- 
ствиям на финальной стадии жизненного цикла отчёта о дефекте”, направ- 
ленным на то, чтобы перевести дефект в состояние «проверен» и «закрыт». 


e Приёмочное тестирование (acceptance їеѕїіпд'%) — формализованное Te- 
стирование, направленное на проверку приложения с точки зрения конечного 
пользователя/заказчика и вынесения решения о том, принимает ли заказчик 
работу у исполнителя (проектной команды). Можно выделить следующие 
подвиды приёмочного тестирования (хотя упоминают их крайне редко, огра- 
ничиваясь в основном общим термином «приёмочное тестирование»): 

о Производственное приёмочное тестирование (factory acceptance 
testing?) — выполняемое проектной командой исследование полноты 
и качества реализации приложения с точки зрения его готовности к пе- 
редаче заказчику. Этот вид тестирования часто рассматривается как 
синоним альфа-тестирования?. 

о Операционное приёмочное тестирование (operational acceptance 
testing, production acceptance testing) — операционное тестирова- 
ние, выполняемое с точки зрения выполнения инсталляции, потреб- 
ления приложением ресурсов, совместимости с программной и аппа- 
ратной платформой ит.д. 

о Итоговое приёмочное тестирование (site acceptance testing") — Te- 
стирование конечными пользователями (представителями заказчика) 
приложения в реальных условиях эксплуатации с целью вынесения 
решения о том, требует ли приложение доработок или может быть Npn- 
нято в эксплуатацию в текущем виде. 





165 Regression testing. Testing of a previously tested program following modification to ensure that defects have пої been introduced 
or uncovered in unchanged areas of the software, as a result of the changes made. It is performed when the software or its 
environment is changed. [ISTQB Glossary] 

166 Frederick Brooks, «The Mythical Man-Month». 


167 Re-testing, Confirmation testing. Testing that runs test cases that failed the last time they were run, in order to verify the success 
of corrective actions. [ISTQB Glossary] 

168 Acceptance Testing. Formal testing with respect to user needs, requirements, and business processes conducted to determine 
whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine 
whether or not to accept the system. [ISTQB Glossary] 

169 Factory acceptance testing. Acceptance testing conducted at the site at which the product is developed and performed by 
employees of the supplier organization, to determine whether or not a component or system satisfies the requirements, normally 
including hardware as well as software. [ISTQB Glossary] 

170 Operational acceptance testing, Production acceptance testing. Operational testing in the acceptance test phase, typically 
performed in a (simulated) operational environment by operations and/or systems administration staff focusing on operational 
aspects, e.g. recoverability, resource-behavior, installability and technical compliance. [ISTQB Glossary] 

171 Site acceptance testing. Acceptance testing by users/customers at their site, to determine whether or not a component or system 
satisfies the user/customer needs and fits within the business processes, normally including hardware as well as software. 
[ISTQB Glossary] 
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e Операционное тестирование (operational їеѕїііпо'72) — тестирование, прово- 
димое в реальной или приближенной к реальной операционной среде 
(operational environments), включающей операционную систему, системы 
управления базами данных, серверы приложений, веб-серверы, аппаратное 
обеспечение и т.д. 


e Тестирование удобства использования (иза Пу!” testing) — тестирова- 
ние, направленное на исследование того, насколько конечному пользова- 
телю понятно, как работать с продуктом (ипаегѕїапаабіііїу"”, Іеагпабііќу"?е, op- 
erability17), а также на то, насколько ему нравится использовать продукт 
(айгасіїуепеѕѕ'”). И это не оговорка — очень часто успех продукта зависит 
именно от эмоций, которые он вызывает у пользователей. Для эффективного 
проведения этого вида тестирования требуется реализовать достаточно се- 
рьёзные исследования с привлечением конечных пользователей, проведе- 
нием маркетинговых исследований ит.д. 





‚ Важно! Тестирование удобства использования (usability testing) и 





| ‚ тестирование интерфейса пользователя (GUI {езйпд'зз) — не одно | 
| и то же! Например, корректно работающий интерфейс может быть | 
неудобным, а удобный может работать некорректно. 





e Тестирование доступности (accessibility testing?) — тестирование, направ- 
ленное на исследование пригодности продукта к использованию людьми с 
ограниченными возможностями (слабым зрением и т.д.). 


e Тестирование интерфейса (interface testing'®) — тестирование, направлен- 
ное на проверку интерфейсов приложения или его компонентов. По опреде- 
лению І5ТОВ-глоссария этот вид тестирования относится к интеграционному 
тестированию?"4%, и это вполне справедливо для таких его вариаций как Te- 
стирование интерфейса прикладного программирования (АРІ testing'8t) и nH- 
терфейса командной строки (CLI testingt82), хотя последнее может выступать 
и как разновидность тестирования пользовательского интерфейса, если че- 
рез командную строку с приложением взаимодействует пользователь, а не 
другое приложение. Однако многие источники предлагают включить в состав 
тестирования интерфейса и тестирование непосредственно интерфейса 
пользователя (GUI testing's3). 





172 Operational testing. Testing conducted to evaluate a component or system in its operational environment. [ISTQB Glossary] 
173 Operational environment. Hardware and software products installed at users’ or customers’ sites where the component or system 


under test will be used. The software may include operating systems, database management systems, and other applications. 
[ISTQB Glossary] 

174 Usability. The capability of the software to be understood, learned, used and attractive to the user when used under specified 
conditions. [ISTQB Glossary] 

175 Understandability. The capability of the software product to enable the user to understand whether the software is suitable, and 
how it can be used for particular tasks and conditions of use. [ISTQB Glossary] 

176 Learnability. The capability of the software product to enable the user to learn its application. [ISTQB Glossary] 

177 Operability. The capability of the software product to enable the user to operate and control it. [ISTQB Glossary] 

178 Attractiveness. The capability of the software product to be attractive to the user. [ISTQB Glossary] 

179 Accessibility testing. Testing to determine the ease by which users with disabilities can use a component or system. [ISTQB 
Glossary] 

180 Interface Testing. An integration test type that is concerned with testing the interfaces between components or systems. [ISTQB 
Glossary] 


181 API testing. Testing performed by submitting commands to the software under test using programming interfaces of the applica- 
tion directly. [ISTQB Glossary] 


182 CLI testing. Testing performed by submitting commands to the software under test using a dedicated command-line interface. 
[ISTQB Glossary] 
183 GUI testing. Testing performed by interacting with the software under test via the graphical user interface. [ISTQB Glossary] 
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Важно! Тестирование интерфейса пользователя (GUI їезїїпд'#з) n 
тестирование удобства использования (usability14 testing) — не 
одно и то же! Например, удобный интерфейс может работать He- | 
‚ корректно, а корректно работающий интерфейс может быть неудоб- 
ным. 








e Тестирование безопасности (security 1е$їїпд'#ё) — тестирование, направ- 
ленное на проверку способности приложения противостоять злонамеренным 
попыткам получения доступа к данным или функциям, права на доступ к ко- 
торым у злоумышленника нет. 





Подробнее про этот вид тестирования можно почитать в статье 
What is Security testing іп software їеѕііпо?» 185. 








e Тестирование интернационализации (internationalization testing, 118п test- 
ing, globalization% testing, localizability'87 testing) — тестирование, направлен- 
ное на проверку готовности продукта к работе с использованием различных 
языков и с учётом различных национальных и культурных особенностей. 
Этот вид тестирования не подразумевает проверки качества соответствую- 
щей адаптации (этим занимается тестирование локализации, см. следующий 
пункт), оно сфокусировано именно на проверке возможности такой адапта- 
ции (например: что будет, если открыть файл с иероглифом в имени; как бу- 
дет работать интерфейс, если всё перевести на японский; может ли прило- 
жение искать данные в тексте на корейском и т.д.). 


e Тестирование локализации (localization 1есїїпд'®, 110п) — тестирование, 
направленное на проверку корректности и качества адаптации продукта к ис- 
пользованию на том или ином языке с учётом национальных и культурных 
особенностей. Это тестирование следует за тестированием интернациона- 
лизации (см. предыдущий пункт) и проверяет корректность перевода и адап- 
тации продукта, а не готовность продукта к таким действиям. 


e Тестирование совместимости (compatibility testing, interoperability іеѕіітот89) 
— тестирование, направленное на проверку способности приложения рабо- 
тать в указанном окружении. Здесь, например, может проверяться: 

о Совместимость с аппаратной платформой, операционной системой и 
сетевой инфраструктурой (конфигурационное тестирование, configura- 
tion testingt). 





184 Security testing. Testing to determine the security of the software product. [ISTQB Glossary] 

185 «What is Security testing in software testing?» [http://istqbexamcertification.com/what-is-security-testing-in-software/] 

186 Globalization. The process of developing a program core whose features and code design are not solely based on a single 
language or locale. Instead, their design is developed for the input, display, and output of a defined set of Unicode-supported 
language scripts and data related to specific locales. [«Globalization Step-by-Step», httos://docs.microsoft.com/en-us/globaliza- 
tion/] 

187 Localizability. The design of the software code base and resources such that a program can be localized into different language 
editions without any changes to the source code. [«Globalization Step-by-Step», httpos://docs.microsoft.com/en-us/globalization/] 

188 Localization testing checks the quality of a product's localization for a particular target culture/locale. This test is based on the 
results of globalization testing, which verifies the functional support for that particular culture/locale. Localization testing can be 
executed only on the localized version of a product. [«Globalization Step-by-Step», https://docs.microsoft.com/en-us/globaliza- 
tion/] 

189 Compatibility Testing, Interoperability Testing. The process of testing to determine the interoperability of a software product 
(the capability to interact with one or more specified components or systems). [ISTQB Glossary] 

190 Configuration Testing, Portability Testing. The process of testing to determine the portability of a software product (the ease 
with which the software product can be transferred from one hardware or software environment to another). [ISTQB Glossary] 
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о Совместимость с браузерами и их версиями (кросс-браузерное тести- 
рование, cross-browser testing’). (См. также тестирование веб-прило- 
жений"). 

о Совместимость с мобильными устройствами (mobile testing). (См. 
также тестирование мобильных приложений N). 

о Итак далее. 


В некоторых источниках к тестированию совместимости добавляют (хоть и 
подчёркивая, что это — не его часть) т.н. тестирование соответствия 
(compliance їеѕііпо"з, conformance testing, regulation testing). 





Рекомендуется ознакомиться с дополнительным материалом по Te- 
‚ стированию совместимости с мобильными платформами в статьях | 
«What is Mobile Теѕііпо?»'% и «Ведтпег$ Guide to Mobile Application | 
Testing». 








• Тестирование данных (data quality! testing) и баз данных (database integ- 
rity testing!) — два близких по смыслу вида тестирования, направленных на 
исследование таких характеристик данных, как полнота, непротиворечи- 
вость, целостность, структурированность и т.д. В контексте баз данных ис- 
следованию может подвергаться адекватность модели предметной области, 
способность модели обеспечивать целостность и консистентность данных, 
корректность работы триггеров, хранимых процедур и т.д. 


e Тестирование использования ресурсов (resource utilization іеѕііпо'®, effi- 
ciency testing’, storage testing?) — совокупность видов тестирования, про- 
веряющих эффективность использования приложением доступных ему ре- 
сурсов и зависимость результатов работы приложения от количества доступ- 
ных ему ресурсов. Часто эти виды тестирования прямо или косвенно примы- 
кают к техникам тестирования производительностиз. 





191 Сгоѕѕ-ргомѕег testing helps уои ensure that your web site ог web application functions correctly іп various web browsers. 
Typically, QA engineers create individual tests for each browser or create tests that use lots of conditional statements that check 
the browser type used and execute browser-specific commands. [https://www.browserstack.com/cross-browser-testing] 

192 Mobile testing is a testing with multiple operating systems (and different versions of each OS, especially with Android), multiple 
devices (different makes and models of phones, tablets, phablets), multiple carriers (including international ones), multiple 
speeds of data transference (3G, LTE, Wi-Fi), multiple screen sizes (and resolutions and aspect ratios), multiple input controls 
(including BlackBerry’s eternal physical keypads), and multiple technologies — GPS, accelerometers — that web and desktop 
apps almost never use. [https:/www.perfecto.io/blog/mobile-testing] 

193 Compliance testing, Conformance testing, Regulation testing. The process of testing to determine the compliance of the 
component or system (the capability to adhere to standards, conventions or regulations in laws and similar prescriptions). [ISTQB 
Glossary] 

194 «What Is Mobile Testing?» [https://www.perfecto.io/blog/mobile-testing] 

195 «Beginner's Guide to Mobile Application Testing» [http://www.softwaretestinghelp.com/beginners-guide-to-mobile-application- 
testing/] 

196 Data quality. An attribute of data that indicates correctness with respect to some pre-defined criteria, e.g., business expectations, 
requirements on data integrity, data consistency. [ISTQB Glossary] 

197 Database integrity testing. Testing the methods and processes used to access and manage the data(base), to ensure access 
methods, processes and data rules function as expected and that during access to the database, data is not corrupted or unex- 
pectedly deleted, updated or created. [ISTQB Glossary] 

198 Resource utilization testing, Storage testing. The process of testing to determine the resource-utilization of a software product. 
[ISTQB Glossary] 

199 Efficiency testing. The process of testing to determine the efficiency of a software product (the capability of a process to produce 
the intended outcome, relative to the amount of resources used). [ISTQB Glossary] 

200 Storage testing. This is a determination of whether or not certain processing conditions use more storage (memory) than esti- 
mated. [«Software Testing Concepts And Tools», Nageshwar Rao Pusuluri] 
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e Сравнительное тестирование (comparison testing) — тестирование, 
направленное на сравнительный анализ преимуществ и недостатков разра- 
батываемого продукта по отношению к его основным конкурентам. 


e Демонстрационное тестирование (qualification testing?) — формальный 
процесс демонстрации заказчику продукта с целью подтверждения, что про- 
дукт соответствует всем заявленным требованиям. В отличие от приёмоч- 
ного тестирования! этот процесс более строгий и всеобъемлющий, но MO- 
жет проводиться и на промежуточных стадиях разработки продукта. 


e Исчерпывающее тестирование (exhaustive testing?) — тестирование npn- 
ложения со всеми возможными комбинациями всех возможных входных дан- 
ных во всех возможных условиях выполнения. Для сколь бы то ни было слож- 
ной системы нереализуемо, но может применяться для проверки отдельных 
крайне простых компонентов. 


e Тестирование надёжности (reliability testing?) — тестирование способности 
приложения выполнять свои функции в заданных условиях на протяжении 
заданного времени или заданного количества операций. 


e Тестирование восстанавливаемости (recoverability testing?) — тестирова- 
ние способности приложения восстанавливать свои функции и заданный 
уровень производительности, а также восстанавливать данные в случае воз- 
никновения критической ситуации, приводящей к временной (частичной) 
утрате работоспособности приложения. 


e Тестирование отказоустойчивости (failover testing) — тестирование, 3a- 
ключающееся в эмуляции или реальном создании критических ситуаций с 
целью проверки способности приложения задействовать соответствующие 
механизмы, предотвращающие нарушение работоспособности, производи- 
тельности и повреждения данных. 


e Тестирование производительности (performance testing?) — исследова- 
ние показателей скорости реакции приложения на внешние воздействия при 
различной по характеру и интенсивности нагрузке. В рамках тестирования 
производительности выделяют следующие подвиды: 

о Нагрузочное тестирование (load їеѕііпд2%, capacity testing?) — иссле- 
дование способности приложения сохранять заданные показатели ка- 
чества при нагрузке в допустимых пределах и некотором превышении 
этих пределов (определение «запаса прочности»). 





201 Comparison testing. Testing that compares software weaknesses апа strengths їо those ої competitors' products. [«ЗоЁ\маге 
Testing and Quality Assurance», Jyoti J. Malhotra, Bhavana S. Tiple] 

202 Qualification testing. Formal testing, usually conducted by the developer for the consumer, to demonstrate that the software 
meets its specified requirements. [«Software Testing Concepts And Tools», Nageshwar Rao Pusuluri] 

203 Exhaustive testing. A test approach in which the test suite comprises all combinations of input values and preconditions. [ISTQB 
Glossary] 

204 Reliability Testing. The process of testing to determine the reliability of a software product (the ability of the software product to 
perform its required functions under stated conditions for a specified period of time, or for a specified number of operations). 
[ISTQB Glossary] 

205 Recoverability Testing. The process of testing to determine the recoverability of a software product (the capability of the software 
product to re-establish a specified level of performance and recover the data directly affected in case of failure). [ISTQB Glossary] 

206 Failover Testing. Testing by simulating failure modes or actually causing failures in a controlled environment. Following a failure, 
the failover mechanism is tested to ensure that data is not lost or corrupted and that any agreed service levels are maintained 
(e.g., function availability or response times). [ISTQB Glossary] 

207 Performance Testing. The process of testing to determine the performance of a software product. [ISTQB Glossary] 

208 Load Testing. A type of performance testing conducted to evaluate the behavior of a component or system with increasing load, 
e.g. numbers of parallel users and/or numbers of transactions, to determine what load can be handled by the component or 
system. [ISTQB Glossary] 

209 Capacity Testing. Testing to determine how many users and/or transactions a given system will support and still meet perfor- 
mance goals. [https://msdn.microsoft.com/en-us/library/bb924357 .aspx] 
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о Тестирование масштабируемости (scalability testing?) — исследова- 
ние способности приложения увеличивать показатели производитель- 
ности в соответствии с увеличением количества доступных приложе- 
нию ресурсов. 

о Объёмное тестирование (volume testing?) — исследование произво- 
дительности приложения при обработке различных (как правило, 
больших) объёмов данных. 

о Стрессовое тестирование (stress іеѕііпо2'2) — исследование поведе- 
ния приложения при нештатных изменениях нагрузки, значительно 
превышающих расчётный уровень, или в ситуациях недоступности 
значительной части необходимых приложению ресурсов. Стрессовое 
тестирование может выполняться и вне контекста нагрузочного тести- 
рования: тогда оно, как правило, называется «тестированием на раз- 
рушение» (destructive testing?!) и представляет собой крайнюю форму 
негативного тестирования“. 

о Конкурентное тестирование (concurrency testing?) — исследование 
поведения приложения в ситуации, когда ему приходится обрабаты- 
вать большое количество одновременно поступающих запросов, что 
вызывает конкуренцию между запросами за ресурсы (базу данных, па- 
мять, канал передачи данных, дисковую подсистему ит.д.). Иногда под 
конкурентным тестированием понимают также исследование работы 
многопоточных приложений и корректность синхронизации действий, 
производимых в разных потоках. 


В качестве отдельных или вспомогательных техник в рамках тестирования 
производительности могут использоваться тестирование использования 
ресурсов”, тестирование надёжности®, тестирование восстанавливаемо- 
сти®, тестирование отказоустойчивости 8 и т.д. 





Подробное рассмотрение нескольких видов тестирования произво- 
‚ дительности приведено в статье «Автоматизация тестирования | 
‚ производительности: основные положения и области примене- 
‚ НИЯ»215. 











210 Scalability Testing. Testing to determine the scalability of the software product (the capability of the software product to Бе 
upgraded to accommodate increased loads). [ISTQB Glossary] 
211 Volume Testing. Testing where the system is subjected to large volumes of data. [ISTQB Glossary] 
212 Stress testing. A type of performance testing conducted to evaluate a system or component at or beyond the limits of its antici- 
pated or specified workloads, or with reduced availability of resources such as access to memory or servers. [ISTQB Glossary] 
213 Destructive software testing assures proper or predictable software behavior when the software is subject to improper usage or 
improper input, attempts to crash a software product, tries to crack or break a software product, checks the robustness of a 
software product. [«Towards Destructive Software Testing», Kiumi Akingbehin] 
214 Concurrency testing. Testing to determine how the occurrence of two or more activities within the same interval of time, achieved 
either by interleaving the activities or by simultaneous execution, is handled by the component or system. [ISTQB Glossary] 
«Автоматизация тестирования производительности: основные положения и области применения» 
[http://svyatoslav.biz/technologies/performance_testing/] 


215 
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2.3.2.13. Классификация по техникам и подходам 
e Позитивное тестирование (рассмотрено ранее?°)). 
e Негативное тестирование (рассмотрено ранее"). 


e Тестирование на основе опыта тестировщика, сценариев, чек-листов: 
о Исследовательское тестирование (рассмотрено ранее 2). 
о Свободное (интуитивное) тестирование (рассмотрено ранее 2). 
e Классификация по степени вмешательства в работу приложения: 
о Инвазивное тестирование (intrusive іеѕїіпо2'6) — тестирование, Bbl- 
полнение которого может повлиять на функционирование приложения 
в силу работы инструментов тестирования (например, будут искажены 
показатели производительности) или в силу вмешательства (level of 
іпігиѕіоп2'7) в сам код приложения (например, для анализа работы npn- 
ложения было добавлено дополнительное протоколирование, вклю- 
чён вывод отладочной информации и т.д.). Некоторые источники рас- 
сматривают?' инвазивное тестирование как форму негативного?» или 
даже стрессового тестирования. 
о Неинвазивное тестирование (nonintrusive іеѕііпо2'°) — тестирование, 
выполнение которого незаметно для приложения и не влияет на про- 
цесс его обычной работы. 


• Классификация по техникам автоматизации: 

о Тестирование под управлением данными (data-driven іеѕїіто220) — 
способ разработки автоматизированных тест-кейсов, в котором вход- 
ные данные и ожидаемые результаты выносятся за пределы тест- 
кейса и хранятся вне его — в файле, базе данных и т.д. 

о Тестирование под управлением ключевыми словами (Кеумога- 
driven testing?) — способ разработки автоматизированных тест-кей- 
сов, в котором за пределы тест-кейса выносится не только набор вход- 
ных данных и ожидаемых результатов, но и логика поведения тест- 
кейса, которая описывается ключевыми словами (командами). 

о Тестирование под управлением поведением (behavior-driven test- 
ing???) — способ разработки автоматизированных тест-кейсов, в KOTO- 
ром основное внимание уделяется корректности работы бизнес-сце- 
нариев, а не отдельным деталям функционирования приложения. 





216 Intrusive testing. Testing that collects timing апа processing information during program execution that тау change the behavior 
of the software from its behavior in a real environment. Intrusive testing usually involves additional code embedded in the software 
being tested or additional processes running concurrently with software being tested on the same processor. [http://encyclope- 
dia2.thefreedictionary.com/intrusive+testing] 

217 Level of intrusion. The level to which a test object is modified by adjusting it for testability. [ISTQB Glossary] 

218 Intrusive testing can be considered a type of interrupt testing, which is used to test how well a system reacts to intrusions and 
interrupts to its normal workflow. [http://www.techopedia.com/definition/7802/intrusive-testing] 

219 Nonintrusive Testing. Testing that is transparent to the software under test, i.e., does not change its timing or processing char- 
acteristics. Nonintrusive testing usually involves additional hardware that collects timing or processing information and processes 
that information on another platform. [http://encyclopedia2.thefreedictionary.com/nonintrusive+testing] 

220 Data-driven Testing (DDT). A scripting technique that stores test input and expected results in a table or spreadsheet, so that a 
single control script can execute all of the tests in the table. Data-driven testing is often used to support the application of test 
execution tools such as capture/playback tools. [ISTQB Glossary] 

221 Keyword-driven Testing (KDT). A scripting technique that uses data files to contain not only test data and expected results, but 
also keywords related to the application being tested. The keywords are interpreted by special supporting scripts that are called 
by the control script or the test. [ISTQB Glossary] 

222 Behavior-driven Testing (ВОТ). Behavior-driven Tests focuses on the behavior rather than the technical implementation of the 
software. If you want to emphasize on business point of view and requirements then BDT is the way to go. BDT are Given-when- 
then style tests written in natural language which are easily understandable to non-technical individuals. Hence these tests allow 
business analysts and management people to actively participate in test creation and review process. [Jyothi Rangaiah, 
http:/www.womentesters.com/behaviour-driven-testing-an-introduction/] 
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e Классификация на основе (знания) источников ошибок: 

о Тестирование предугадыванием ошибок (error guessing?) — Tex- 
ника тестирования, в которой тесты разрабатываются на основе опыта 
тестировщика и его знаний о том, какие дефекты типичны для тех или 
иных компонентов или областей функциональности приложения. Мо- 
жет комбинироваться с техникой т.н. «ошибкоориентированного» те- 
стирования (failure-directed testing??4), в котором новые тесты строятся 
на основе информации о ранее обнаруженных в приложении пробле- 
мах. 

о Эвристическая оценка (heuristic evaluation?) — техника тестирова- 
ния удобства использования, направленная на поиск проблем в MH- 
терфейсе пользователя, представляющих собой отклонение от обще- 
принятых норм. 

о Мутационное тестирование (mutation testing?) — техника тестирова- 
ния, в которой сравнивается поведение нескольких версий одного и 
того же компонента, причём часть таких версий может быть специ- 
ально разработана с добавлением ошибок (что позволяет оценить эф- 
фективность тест-кейсов — качественные тесты обнаружат эти специ- 
ально добавленные ошибки). Может комбинироваться со следующим 
в этом списке видом тестирования (тестированием добавлением оши- 
бок). 

о Тестирование добавлением ошибок (error ѕеедіпд227) — техника Te- 
стирования, в которой в приложение специально добавляются зара- 
нее известные, специально продуманные ошибки с целью монито- 
ринга их обнаружения и устранения и, таким образом, формирования 
более точной оценки показателей процесса тестирования. Может ком- 
бинироваться с предыдущим в этом списке видом тестирования (мута- 
ционным тестированием). 


• Классификация на основе выбора входных данных: 

о Тестирование на основе классов эквивалентности (едимаепсе 
рагійіопіпо228) — техника тестирования, направленная на сокращение 
количества разрабатываемых и выполняемых тест-кейсов при сохра- 
нении достаточного тестового покрытия. Суть техники состоит в выяв- 
лении наборов эквивалентных тест-кейсов (каждый из которых прове- 
ряет одно и то же поведение приложения) и выборе из таких наборов 
небольшого подмножества тест-кейсов, с наибольшей вероятностью 
обнаруживающих проблему. 





223 Error Guessing. А test design technique where the experience ої the tester is used їо anticipate what defects might be present 
in the component or system under test as a result of errors made, and to design tests specifically to expose them. [ISTQB 
Glossary] 

224 Failure-directed Testing. Software testing based оп the knowledge of the types of errors made in the past that are likely for the 
system under test. [https://www.techopedia.com/definition/7129/failure-directed-testing]. 

225 Heuristic Evaluation. A usability review technique that targets usability problems in the user interface or user interface design. 
With this technique, the reviewers examine the interface and judge its compliance with recognized usability principles (the «heu- 
ristics»). [ISTQB Glossary] 

226 Mutation Testing, Back-to-Back Testing. Testing in which two or more variants of a component or system are executed with the 
same inputs, the outputs compared, and analyzed in cases of discrepancies. [ISTQB Glossary] 

227 Error seeding. The process of intentionally adding known faults to those already in a computer program for the purpose of 
monitoring the rate of detection and removal, and estimating the number of faults remaining in the program. [ISTQB Glossary] 

228 Equivalence partitioning. A black box test design technique in which test cases are designed to execute representatives from 
equivalence partitions. In principle test cases are designed to cover each partition at least once. [ISTQB Glossary] 
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о Тестирование на основе граничных условий (boundary value analy- 
$15229) — инструментальная техника тестирования на основе классов 
эквивалентности, позволяющая выявить специфические значения ис- 
следуемых параметров, относящиеся к границам классов эквивалент- 
ности. Эта техника значительно упрощает выявление наборов эквива- 
лентных тест-кейсов и выбор таких тест-кейсов, которые обнаружат 
проблему с наибольшей вероятностью. 

о Доменное тестирование (domain апа!у51523°, domain testing) — техника 
тестирования на основе классов эквивалентности и граничных усло- 
вий, позволяющая эффективно создавать тест-кейсы, затрагивающие 
несколько параметров (переменных) одновременно (в том числе с учё- 
том взаимозависимости этих параметров). Данная техника также опи- 
сывает подходы к выбору минимального множества показательных 
тест-кейсов из всего набора возможных тест-кейсов. 

о Попарное тестирование (pairwise testing?') — техника тестирования, 
в которой тест-кейсы строятся по принципу проверки пар значений па- 
раметров (переменных) вместо того, чтобы пытаться проверить все 
возможные комбинации всех значений всех параметров. Эта техника 
является частным случаем М№-комбинационного тестирования (п-міѕе 
testing?) и позволяет существенно сократить трудозатраты на тести- 
рование (а иногда и вовсе сделать возможным тестирование в случае, 
когда количество «всех комбинаций всех значений всех параметров» 
измеряется миллиардами). 






‚ Попарное тестирование (pairwise testing?) — это НЕ парное Te- 
‚ стирование (pair їіеѕїітогзз)! , 





о Тестирование на основе ортогональных массивов (orthogonal array 
їеѕііпо2*) — инструментальная техника попарного и N- 
комбинационного тестирования, основанная на использовании т.н. 
«ортогональных массивов» (двумерных массивов, обладающих следу- 
ющим свойством: если взять две любые колонки такого массива, то 
получившийся «подмассив» будет содержать все возможные попар- 
ные комбинации значений, представленных в исходном массиве). 





Ортогональные массивы — это НЕ ортогональные матрицы. Это | 
‚ совершенно разные понятия! Сравните их описания в статьях 








223 Boundary value analysis. А black box test design technique іп which test cases аге designed based оп boundary values (при 
values or output values which are on the edge of an equivalence partition or at the smallest incremental distance on either side 
of an edge, for example the minimum or maximum value of a range). [ISTQB Glossary] 

230 Domain analysis. A black box test design technique that is used to identify efficient and effective test cases when multiple varia- 
bles can or should be tested together. It builds on and generalizes equivalence partitioning and boundary values analysis. [ISTQB 
Glossary] 

231 Pairwise testing. A black box test design technique in which test cases are designed to execute all possible discrete combinations 
of each pair of input parameters. [ISTQB Glossary] 

232 N-wise testing. A black box test design technique in which test cases are designed to execute all possible discrete combinations 
of any set of n input parameters. [ISTQB Glossary] 

233 Pair testing. Two persons, e.g. two testers, a developer and a tester, or an end-user and a tester, working together to find defects. 
Typically, they share one computer and trade control of it while testing. [ISTQB Glossary] 

234 Orthogonal array testing. A systematic way of testing all-pair combinations of variables using orthogonal arrays. It significantly 
reduces the number of all combinations of variables to test all pair combinations. See also combinatorial testing, n-wise testing, 
pairwise testing. [ISTQB Glossary] 

235 «Orthogonal array», Wikipedia. [http://en.wikipedia.org/wiki/Orthogonal_array] 

236 «Orthogonal matrix», Wikipedia. [http://en.wikipedia.org/wiki/Orthogonal matrix] 
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Также см. комбинаторные техники тестирования, которые расши- 
ряют и дополняют только что рассмотренный список видов тестирова- 
ния на основе выбора входных данных. 





‚ Крайне подробное описание некоторых видов тестирования, OTHO- 
сящихся к данной классификации, можно найти в книге Ли Ко- 
’ упленда «Практическое руководство по разработке тестов» (Еее 
Copeland, «А Practitioner's Guide to Software Test Design»), в част- 
ности: 
e Тестирование на основе классов эквивалентности — в главе 3. 
Тестирование на основе граничных условий — в главе 4. | 
Доменное тестирование — в главе 8. | 
Попарное тестирование и тестирование на основе ортогональ- ' 
ных массивов — в главе 6 






Важно! Большинство этих техник входит в «джентльменский набор 
| любого тестировщика», потому их понимание и умение применять _ 
‚ можно считать обязательным. | 





Классификация на основе среды выполнения: 
о Тестирование в процессе разработки (development testing?) — Te- 


стирование, выполняемое непосредственно в процессе разработки 
приложения и/или в среде выполнения, отличной от среды реального 
использования приложения. Как правило, выполняется самими разра- 
ботчиками. 


о Операционное тестирование (рассмотрено ранее). 


Тестирование на основе кода (code based testing). В различных источниках 
эту технику называют по-разному (чаще всего — тестированием на основе 
структур, причём некоторые авторы смешивают в один набор тестирование 
по потоку управления и по потоку данных, а некоторые строго разделяют эти 
стратегии). Подвиды этой техники также организуют в разные комбинации, 
но наиболее универсально их можно классифицировать так: 

о Тестирование по потоку управления (control flow їеѕііпо238) — семей- 


ство техник тестирования, в которых тест-кейсы разрабатываются с 
целью активации и проверки выполнения различных последователь- 
ностей событий, которые определяются посредством анализа исход- 
ного кода приложения. Дополнительное подробное пояснение см. 
дальше в этом разделе (см. тестирование на основе структур кода“). 
Тестирование по потоку данных (data-flow їесїїпд?3°) — семейство 
техник тестирования, основанных на выборе отдельных путей из по- 
тока управления с целью исследования событий, связанных с измене- 
нием состояния переменных. Дополнительное подробное пояснение 
см. дальше в этом разделе (в части, где тестирование по потоку дан- 
ных пояснено с точки зрения стандарта 1ЗОЛЕСЛЕЕЕ 29119-405), 





237 Development testing. Formal ог informal testing conducted during the implementation of а component ог system, usually іп the 
development environment by developers. [ISTQB Glossary] 

238 Control Flow Testing. An approach to structure-based testing in which test cases are designed to execute specific sequences of 
events. Various techniques exist for control flow testing, e.g., decision testing, condition testing, and path testing, that each have 
their specific approach and level of control flow coverage. [ISTQB Glossary] 

239 Data Flow Testing. A white box test design technique in which test cases are designed to execute definition-use pairs of variables. 
[ISTQB Glossary] 
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о Тестирование по диаграмме или таблице состояний (state transition 
їеѕііпог‹0) — техника тестирования, в которой тест-кейсы разрабатыва- 
ются для проверки переходов приложения из одного состояния в дру- 
гое. Состояния могут быть описаны диаграммой состояний (state dia- 
дгат2“") или таблицей состояний (state їабіе22). 





[ кз ‚ Хорошее подробное пояснение по данному виду тестирова-_ 
: ния можно прочесть в статье «What is State transition testing то 





Иногда эту технику тестирования также называют «тестированием по 
принципу конечного автомата» (finite state machine? testing). Важным 
преимуществом этой техники является возможность применения в ней 
теории конечных автоматов (которая хорошо формализована), а также 
возможность использования автоматизации для генерации комбина- 
ций входных данных. 


о Инспекция (аудит) кода (code review, code inspection?) — семейство 
техник повышения качества кода за счёт того, что в процессе создания 
или совершенствования кода участвуют несколько человек. Степень 
формализации аудита кода может варьироваться от достаточно бег- 
лого просмотра до тщательной формальной инспекции. В отличие от 
техник статического анализа кода (по потоку управления и потоку дан- 
ных) аудит кода также улучшает такие его характеристики, как понят- 
ность, поддерживаемость, соответствие соглашениям об оформлении 
и т.д. Аудит кода выполняется в основном самими программистами. 


e Тестирование на основе структур кода (structure-based techniques) предпола- 
гает возможность исследования логики выполнения кода в зависимости от 
различных ситуаций и включает в себя: 

о Тестирование на основе выражений (statement testing?) — техника 
тестирования (по методу белого ящика), в которой проверяется кор- 
ректность (и сам факт) выполнения отдельных выражений в коде. 

о Тестирование на основе ветвей (branch testing?) — техника тести- 
рования (по методу белого ящика), в которой проверяется выполнение 
отдельных ветвей кода (под ветвью понимается атомарная часть кода, 
выполнение которой происходит или не происходит в зависимости от 
истинности или ложности некоторого условия). 





240 State Transition Testing. А black бох test design technique іп which test cases are designed to execute valid апа invalid state 
transitions. [ISTQB Glossary] 

241 State Diagram. A diagram that depicts the states that a component or system can assume, and shows the events or circumstances 

that cause and/or result from a change from one state to another. [ISTQB Glossary] 

State Table. A grid showing the resulting transitions for each state combined with each possible event, showing both valid and 

invalid transitions. [ISTQB Glossary] 

243 «What is State transition testing in software testing?» [http://istqbexamcertification.com/what-is-state-transition-testing-in-soft- 
ware-testing/] 

244 Finite State Machine. A computational model consisting of a finite number of states and transitions between those states, possibly 
with accompanying actions. [ISTQB Glossary] 

245 Inspection. A type of peer review that relies on visual examination of documents to detect defects, e.g. violations of development 
standards and non-conformance to higher level documentation. The most formal review technique and therefore always based 
on a documented procedure. [ISTQB Glossary] 

246 Statement Testing. A white box test design technique in which test cases are designed to execute statements (statement is an 
entity in a programming language, which is typically the smallest indivisible unit of execution). [ISTQB Glossary] 

247 Branch Testing. A white box test design technique in which test cases are designed to execute branches (branch is a basic block 
that can be selected for execution based on a program construct in which one of two or more alternative program paths is 
available, e.g. case, jump, до їо, if-then-else.). [ISTQB Glossary] 


242 
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о Тестирование на основе условий (condition testing?) — техника Te- 
стирования (по методу белого ящика), в которой проверяется выпол- 
нение отдельных условий (условием считается выражение, которое 
может быть вычислено до значения «истина» или «ложь»). 

о Тестирование на основе комбинаций условий (multiple condition 
testing?) — техника тестирования (по методу белого ящика), в которой 
проверяется выполнение сложных (составных) условий. 

о Тестирование на основе отдельных условий, порождающих ветв- 
ление («решающих условий») (modified condition decision coverage 
testing?) — техника тестирования (по методу белого ящика), в которой 
проверяется выполнение таких отдельных условий в составе сложных 
условий, которые в одиночку определяют результат вычисления всего 
сложного условия. 

о Тестирование на основе решений (decision testingt) — техника Te- 
стирования (по методу белого ящика), в которой проверяется выпол- 
нение сложных ветвлений (с двумя и более возможными вариантами). 
Несмотря на то что «два варианта» сюда также подходит, формально 
такую ситуацию стоит отнести к тестированию на основе условий. 

о Тестирование на основе путей (path testing?) — техника тестирова- 
ния (по методу белого ящика), в которой проверяется выполнение всех 
или некоторых специально выбранных путей в коде приложения. 





Если говорить строго научно, то определения большинства видов | 
тестирования на основе структур кода должны звучать чуть-чуть 
иначе, т.к. в программировании условием считается выражение | 
_ без логических операторов, а решением — выражение с логиче- 
’ скими операторами. Но глоссарий ISTQB не делает на этом ак- 
цента, а потому приведённые выше определения можно считать 
‚ корректными. Однако, если вам интересно, рекомендуется озна- 


‚ комиться с заметкой «What is the difference between а Decision and | 
кае 





Кратко вся суть видов тестирования на основе структур кода показана 
в таблице 2.3.с. 





248 Condition Testing. А white бох test design technique іп which test cases аге designed to execute condition outcomes (condition 
is a logical expression that can be evaluated as True or False, e.g. A > B). [ISTQB Glossary] 

249 Multiple Condition Testing. A white box test design technique in which test cases are designed to execute combinations of single 
condition outcomes (within one statement). [ISTQB Glossary] 

250 Modified Condition Decision Coverage Testing. Technique to design test cases to execute branch condition outcomes that 
independently affect a decision outcome and discard conditions that do not affect the final outcome. [«Guide to Advanced Soft- 
ware Testing, Second Edition», Anne Mette Hass]. 

251 Decision Testing. A white box test design technique in which test cases are designed to execute decision outcomes (decision is 
program point at which the control flow has two or more alternative routes, e.g. a node with two or more links to separate 
branches). [ISTQB Glossary] 

252 Path testing. A white box test design technique in which test cases are designed to execute paths. [ISTQB Glossary] 

253 «What is the difference between a Decision апа a Condition?» [http://www-01 .ibm.com/support/docview.wss?uid=swg21129252] 
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Таблица 2.3.с — Виды тестирования на основе структур кода 

















Русскоязычное Англоязычное Суть (что проверяется) 

название название 
Тестирование на ос- Statement testing Отдельные атомарные участки кода, 
нове выражений например х = 10 
Тестирование на ос- Branch testing Проход по ветвям выполнения кода. 
нове ветвей 
Тестирование на oc- Condition testing, Отдельные условные конструкции, 
нове условий Branch Condition Test- | например if (а == b) 

ing 

Тестирование Ha ос- Multiple condition test- | Составные условные конструкции, 
нове комбинаций ing, например if ((а == b) || (с == d)) 
условий Branch Condition 


Combination Testing 
Тестирование Ha oc- | Modified Condition De- | Отдельные условия, в одиночку влияю- 
нове отдельных ycro- | cision Coverage Test- | щие на итог вычисления составного 





вий, порождающих ing условия, например в условии if ((х == у) 
ветвление («решаю- && (п == т)) ложное значение в каждом 
щих условий») из отдельных условий само по себе при- 


водит к результату false вне зависимости 
от результата вычисления второго усло- 








вия 
Тестирование на ос- Decision testing Сложные ветвления, например оператор 
нове решений switch 

Тестирование Ha oc- | Path testing Все или специально выбранные пути 














нове путей 





e Тестирование на основе (моделей) поведения приложения (application behav- 
іог/тоде!-раѕеа testing): 

о Тестирование по таблице принятия решений (decision table test- 
10254) — техника тестирования (по методу чёрного ящика), в которой 
тест-кейсы разрабатываются на основе т.н. таблицы принятия реше- 
ний, в которой отражены входные данные (и их комбинации) и воздей- 
ствия на приложение, а также соответствующие им выходные данные 
и реакции приложения. 

о Тестирование по диаграмме или таблице состояний (рассмотрено 
ранее“). 

о Тестирование по спецификациям (specification-based testing, black 
рох testing) (рассмотрено ранее). 

о Тестирование по моделям поведения приложения (model-based 
їе$їїпд255) — техника тестирования, в которой исследование приложе- 
ния (и разработка тест-кейсов) строится на некой модели: таблице 
принятия решений“, таблице или диаграмме состояний, пользова- 
тельских сценариев!*?, модели нагрузки и т.д. 

о Тестирование на основе вариантов использования (use case test- 
10256) — техника тестирования (по методу чёрного ящика), в которой 
тест-кейсы разрабатываются на основе вариантов использования. Ва- 
рианты использования выступают в основном источником информа- 
ции для шагов тест-кейса, в то время как наборы входных данных 





254 Decision Table Testing. А black бох test design technique іп which test cases аге designed to execute the combinations ої 
inputs and/or stimuli (causes) shown in a decision table (a table showing combinations of inputs and/or stimuli (causes) with their 
associated outputs and/or actions (effects), which can be used to design test cases). [ISTQB Glossary] 

255 Model-based Testing. Testing based on a model of the component or system under test, e.g., reliability growth models, usage 
models such as operational profiles or behavioral models such as decision table or state transition diagram. [ISTQB Glossary] 

256 Use case testing. A black box test design technique in which test cases are designed to execute scenarios of use cases. [ISTQB 
Glossary] 
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удобно разрабатывать с помощью техник выбора входных данных". 
В общем случае источником информации для разработки тест-кейсов 
в этой технике могут выступать не только варианты использования, но 
и другие пользовательские требования?” в любом их виде. В случае 
если методология разработки проекта подразумевает использование 
пользовательских историй, этот вид тестирования может быть заме- 
нён тестированием на основе пользовательских историй (user story 
їеѕііто257). 

о Параллельное тестирование (parallel testing) — техника тестирова- 
ния, в которой поведение нового (или модифицированного) приложе- 
ния сравнивается с поведением эталонного приложения (предположи- 
тельно работающего верно). Термин «параллельное тестирование» 
также может использоваться для обозначения способа проведения те- 
стирования, когда несколько тестировщиков или систем автоматиза- 
ции выполняют работу одновременно, т.е. параллельно. Очень редко 
(и не совсем верно) под параллельным тестированием понимают му- 
тационное тестирование". 

о Тестирование на основе случайных данных (random їеѕїітог259) — 
техника тестирования (по методу чёрного ящика), в которой входные 
данные, действия или даже сами тест-кейсы выбираются на основе 
(псевдо)случайных значений так, чтобы соответствовать операцион- 
ному профилю (operational profilez) — подмножеству действий, соот- 
ветствующих некоей ситуации или сценарию работы с приложением. 
Не стоит путать этот вид тестирования с т.н. «обезьяньим тестирова- 
нием» (monkey testing?®'). 

о А/В-тестирование (A/B testing, split testing?) — техника тестирования, 
в которой исследуется влияние на результат выполнения операции из- 
менения одного из входных параметров. Однако куда чаще можно 
встретить трактовку А/В-тестирования как технику тестирования удоб- 
ства использования, в которой пользователям случайным образом 
предлагаются разные варианты элементов интерфейса, после чего 
оценивается разница в реакции пользователей. 





Крайне подробное описание некоторых видов тестирования, OTHO- 
’ сящихся к данной классификации, можно найти в книге Ли Ko- 
 упленда «Практическое руководство по разработке тестов» (ее | 
‚ Copeland, «А Practitioner's Guide to Software Тез! Design»): | 
[ e Тестирование по таблице принятия решений — в главе 5. 
e Тестирование по диаграмме или таблице состояний — в главе 7. | 
e Тестирование на основе вариантов использования — в главе 9. | 








257 User story testing. А black бох test design technique п which test cases аге designed based оп user stories to verify their correct 
implementation. [ISTQB Glossary] 

258 Parallel testing. Testing a new or an altered data processing system with the same source data that is used in another system. 
The other system is considered as the standard of comparison. [ISPE Glossary] 

259 Random testing. A black box test design technique where test cases are selected, possibly using a pseudo-random generation 
algorithm, to match an operational profile. This technique can be used for testing non-functional attributes such as reliability and 
performance. [ISTQB Glossary] 

260 Operational profile. The representation of a distinct set of tasks performed by the component or system, possibly based on user 
behavior when interacting with the component or system, and their probabilities of occurrence. A task is logical rather that physical 
and can be executed over several machines or be executed in non-contiguous time segments. [ISTQB Glossary] 

261 Monkey testing. Testing by means of a random selection from a large range of inputs and by randomly pushing buttons, ignorant 
of how the product is being used. [ISTQB Glossary] 

262 Split testing is a design for establishing a causal relationship between changes and their influence on user-observable behavior. 
[«Сопігоіеа experiments on the web: survey and practical guide», Ron Kohavi] 
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2.3.2.14. Классификация по моменту выполнения (хронологии) 


Несмотря на многочисленные попытки создать единую хронологию тестиро- 
вания, предпринятые многими авторами, по-прежнему можно смело утверждать, 
что общепринятого решения, которое в равной степени подходило бы для любой 
методологии управления проектами, любого отдельного проекта и любой его ста- 
дии, просто не существует. 

Если попытаться описать хронологию тестирования одной общей фразой, то 
можно сказать, что происходит постепенное наращивание сложности самих тест- 
кейсов и сложности логики их выбора. 


e Общая универсальная логика последовательности тестирования состоит в 
том, чтобы начинать исследование каждой задачи с простых позитивных 
тест-кейсов, к которым постепенно добавлять негативные (но тоже доста- 
точно простые). Лишь после того, как наиболее типичные ситуации покрыты 
простыми тест-кейсами, следует переходить к более сложным (опять же, 
начиная с позитивных). Такой подход — не догма, но к нему стоит прислу- 
шаться, т.к. углубление на начальных этапах в негативные (к тому же — 
сложные) тест-кейсы может привести к ситуации, в которой приложение от- 
лично справляется с кучей неприятностей, но не работает на элементарных 
повседневных задачах. Ещё раз суть универсальной последовательности: 

1) простое позитивное тестирование; 
2) простое негативное тестирование; 
3) сложное позитивное тестирование; 
4) сложное негативное тестирование. 

e Последовательность тестирования, построенная по иерархии компонентов: 

о Восходящее тестирование (bottom-up testing?) — инкрементальный 
подход к интеграционному тестированию”, в котором в первую oye- 
редь тестируются низкоуровневые компоненты, после чего процесс пе- 
реходит на всё более и более высокоуровневые компоненты. 

о Нисходящее тестирование (top-down 1е$їїпд25&) — инкрементальный 
подход к интеграционному тестированию”, в котором в первую оче- 
редь тестируются высокоуровневые компоненты, после чего процесс 
переходит на всё более и более низкоуровневые компоненты. 

о Гибридное тестирование (hybrid testing?) — комбинация восходя- 
щего и нисходящего тестирования, позволяющая упростить и ускорить 
получение результатов оценки приложения. 





| ‚Поскольку термин «гибридное» является синонимом «комби- 
| _нированное», под «гибридным тестированием» может пони- 
‚ маться практически любое сочетание двух и более видов, TeX- 
_ник или подходов к тестированию. Всегда уточняйте, о гибриде 
‚ чего именно идёт речь. 








263 Bottom-up testing. Ап incremental approach їо integration testing where the lowest level components аге tested first, апа then 
used to facilitate the testing of higher level components. This process is repeated until the component at the top of the hierarchy 
is tested. [ISTQB Glossary] 

264 Top-down testing. An incremental approach to integration testing where the component at the top of the component hierarchy is 
tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level compo- 
nents. The process is repeated until the lowest level components have been tested. [ISTQB Glossary] 

265 Hybrid testing, Sandwich testing. First, the inputs for functions are integrated in the bottom-up pattern discussed above. The 
outputs for each function are then integrated in the top-down manner. The primary advantage of this approach is the degree of 
support for early release of limited functionality. [«Integration testing techniques», Kratika Parmar] 
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Последовательность тестирования, построенная по концентрации внимания 
на требованиях и их составляющих: 


1) 


Тестирование требований, которое может варьироваться от беглой 
оценки в стиле «всё ли нам понятно» до весьма формальных под- 
ходов, в любом случае первично по отношению к тестированию 
того, как эти требования реализованы. 

Тестирование реализации функциональных составляющих требо- 
ваний логично проводить до тестирования реализации нефункцио- 
нальных составляющих, т.к. если что-то просто не работает, то про- 
верять производительность, безопасность, удобство и прочие не- 
функциональные составляющие бессмысленно, а чаще всего и во- 
все невозможно. 

Тестирование реализации нефункциональных составляющих тре- 
бований часто становится логическим завершением проверки того, 
как реализовано то или иное требование. 


Типичные общие сценарии используются в том случае, когда не существует 
явных предпосылок к реализации иной стратегии. Такие сценарии могут ви- 
доизменяться и комбинироваться (например, весь «типичный общий сцена- 
рий 1» можно повторять на всех шагах «типичного общего сценария 2»). 

о Типичный общий сценарий 1: 


1) Дымовое тестирование"®. 
2) Тестирование критического пути“?! 
3) Расширенное тестирование. 


о Типичный общий сценарий 2: 


1) Модульное тестирование“. 
2) Интеграционное тестирование”?^. 
3) Системное тестирование. 


о Типичный общий сценарий 3: 


1) Альфа-тестированиев?. 
2) Бета-тестирование в". 
3) Гамма-тестированиев'. 


В завершение ещё раз подчеркнём, что рассмотренные здесь классифика- 
ции тестирования не являются чем-то каноническим и незыблемым. Они лишь при- 
званы упорядочить огромный объём информации о различных видах деятельности 
тестировщиков и упростить запоминание соответствующих фактов. 
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2.3.3. Альтернативные и дополнительные классификации тестиро- 
вания 


Для полноты картины остаётся лишь показать альтернативные взгляды на 
классификацию тестирования. Одна из них (рисунки 2.3.1 и 2.3.ј) представляет не 
более чем иную комбинацию ранее рассмотренных видов и техник. Вторая (рисунки 
2.3.К и 2.3.1) содержит много новых определений, но их подробное изучение выхо- 
дит за рамки данной книги, и потому будут даны лишь краткие пояснения (при необ- 
ходимости вы можете ознакомиться с первоисточниками, которые указаны для каж- 
дого определения в сноске). 


Ещё раз подчеркнём: здесь приведены лишь определения. Соответству- 
: ющим видам и техникам тестирования в первоисточниках посвящены Ae- 
‚ сятки и сотни страниц. Пожалуйста, не ожидайте от этого раздела подроб- | 
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Рисунок 2.3.1 — Классификация тестирования согласно книге «Foundations of Soft- 
ware Testing: ISTQB Certification» (Erik Мап Veenendaal, Isabel Evans) (русскоязыч- 
ный вариант) 
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Testing Techniques 
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| Decision 
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Control Flow 


Data Flow Decision Tables Condition 





State Transition Multiple Condition 





Use Case Testing 


Рисунок 2.3.j — Классификация тестирования согласно книге «Foundations of Soft- 
ware Testing: ISTQB Certification» (Erik Мап Veenendaal, Isabel Evans) (англоязыч- 
ный вариант) 


В следующей классификации встречаются как уже рассмотренные пункты, 
так и ранее не рассмотренные (отмечены пунктирной линией). Краткие определе- 
ния не рассмотренных ранее видов тестирования представлены после рисунков 
2.3.К и 2.3.1. 
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Рисунок 2.3.К — Классификация тестирования согласно ІЅОЛЕСЛЕЕЕ 29119-4 


(русскоязычный вариант) 
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Рисунок 2.3.1 — Классификация тестирования согласно ІЅОЛЕСЛЕЕЕ 29119-4 (ан- 
глоязычный вариант) 
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e Тестирование на основе дерева классификаций (classification ігее28 
теіһћоа27) — техника тестирования (по методу чёрного ящика), в которой 
тест-кейсы создаются на основе иерархически организованных наборов эк- 
вивалентных входных и выходных данных. 


e Тестирование на основе синтаксиса (syntax їеѕііпд268) — техника тестиро- 
вания (по методу чёрного ящика), в которой тест-кейсы создаются на основе 
определения наборов входных и выходных данных. 


e Комбинаторные техники или комбинаторное тестирование (combinatorial 
testing?) — способ выбрать подходящий набор комбинаций тестовых данных 
для достижения установленного уровня тестового покрытия в случае, когда 
проверка всех возможных наборов значений тестовых данных невозможна за 
имеющееся время. Существуют следующие комбинаторные техники: 

о Тестирование всех комбинаций (all combinations testing??) — тести- 
рование всех возможных комбинаций всех значений всех тестовых 
данных (например, всех параметров функции). 

о Попарное тестирование (рассмотрено ранее). 

о Тестирование с выбором значений-представителей (each choice 
testing?) — тестирование, при котором по одному значению из каждого 
набора тестовых данных должно быть использовано хотя бы в одном 
тест-кейсе. 

о Тестирование с выбором базового набора значений (base choice 
їеѕііпо272) — тестирование, при котором выделяется набор значений 
(базовый набор), который используется для проведения тестирования 
в первую очередь, а далее тест-кейсы строятся на основе выбора всех 
базовых значений, кроме одного, которое заменяется значением, не 
входящим в базовый набор. 


Также см. классификацию тестирования на основе выбора входных 
данных?, которая расширяет и дополняет данный список. 


e Тестирование по графу причинно-следственных связей (cause-effect gra- 
рһіпо27з) — техника тестирования (по методу чёрного ящика), в которой тест- 
кейсы разрабатываются на основе графа причинно-следственных связей 
(графического представления входных данных и воздействий со связанными 
с ними выходными данными и эффектами). 





266 Classification tree. А tree showing equivalence partitions hierarchically ordered, which is used їо design test cases іп the classi- 
fication tree method. [ISTQB Glossary] 

267 Classification tree method. A black box test design technique in which test cases, described by means of a classification tree, 
are designed to execute combinations of representatives of input and/or output domains. [ISTQB Glossary] 

268 Syntax testing. A black box test design technique in which test cases are designed based upon the definition of the input domain 
and/or output domain. [ISTQB Glossary] 

269 Combinatorial testing. A means to identify a suitable subset of test combinations to achieve a predetermined level of coverage 
when testing an object with multiple parameters and where those parameters themselves each have several values, which gives 
rise to more combinations than are feasible to test in the time allowed. [ISTQB Glossary] 

270 All combinations testing. Testing of all possible combinations of all values for all parameters. [«Guide to advanced software 
testing, 2nd edition», Anne Matte Hass]. 

271 Each choice testing. One value from each block for each partition must be used in at least one test case. [«Introduction to 
Software Testing. Chapter 4. Input Space Partition Testing», Paul Ammann & Jeff Offutt] 

272 Base choice testing. A base choice block is chosen for each partition, and a base test is formed by using the base choice for 
each partition. Subsequent tests are chosen by holding all but one base choice constant and using each non-base choice in 
each other parameter. [«Introduction to Software Testing. Chapter 4. Input Space Partition Testing», Paul Ammann & Jeff Offutt] 

273 Cause-effect graphing. A black box test design technique in which test cases are designed from cause-effect graphs (a graphical 
representation of inputs and/or stimuli (causes) with their associated outputs (effects), which can be used to design test cases). 
[ISTQB Glossary] 
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Тестирование по потоку данных (data-flow testing?) — семейство техник 
тестирования, основанных на выборе отдельных путей из потока управления 
с целью исследования событий, связанных с изменением состояния пере- 
менных. Эти техники позволяют обнаружить такие ситуации, как: переменная 
определена, но нигде не используется; переменная используется, но не 
определена; переменная определена несколько раз до того, как она исполь- 
зуется; переменная удалена до последнего случая использования. 


Здесь придётся немного погрузиться в теорию. Над переменной в общем слу- 
чае может выполняться несколько действий (покажем на примере перемен- 
ной Х): 

e объявление (declaration): int х; 

• определение (definition, d-use): х = 99; 

• использование в вычислениях (computation use, с-изе): 2 = х + 1; 

• использование в условиях (predicate use, р-изе): if (х > 17) {... }; 

e удаление (КИ, К-изе): х = null; 


Теперь можно рассмотреть техники тестирования на основе потока данных. 
Они крайне подробно описаны в разделе 3.3 главы 5 книги Бориса Бейзера 
«Техники тестирования ПО» («Software Testing Techniques, Second Edition», 
Boris Beizer), мы же приведём очень краткие пояснения: 

о Проверка использования всех объявлений (all-definitions testing?) 
— тестовым набором проверяется, что для каждой переменной суще- 
ствует путь от её определения к её использованию в вычислениях или 
условиях. 

о Проверка всех вычислений на основе всех объявлений (all-c-uses 
їе$їїпд?%) — тестовым набором проверяется, что для каждой перемен- 
ной существует путь от каждого её определения к её использованию B 
вычислениях. 

о Проверка всех ветвлений на основе всех объявлений (all-p-uses 
testing?) — тестовым набором проверяется, что для каждой перемен- 
ной существует путь от каждого её определения к её использованию B 
условиях. 

о Проверка всех вычислений и ветвлений на основе всех объявле- 
ний (а11-иѕеѕ їесїїпд?%) — тестовым набором проверяется, что для каж- 
дой переменной существует хотя бы один путь от каждого её опреде- 
ления к каждому её использованию в вычислениях и в условиях. 

о Проверка использования всех объявлений и всех путей без пере- 
объявлений (без циклов или с однократными повторениями цик- 
лов) (all-du-paths testing?!) — тестовым набором для каждой перемен- 
ной проверяются все пути от каждого её определения к каждому её 
использованию в вычислениях и в условиях (самая мощная стратегия, 
которая в то же время требует наибольшего количества тест-кейсов). 





274 Data Ном testing. А white бох test design technique іп which test cases аге designed to execute definition-use pairs ої variables. 
[ISTQB Glossary] 

275 All-definitions strategy. Test set requires that every definition of every variable is covered by at least one use of that variable (c- 
use or р-изе). [«Software Testing Techniques, Second Edition», Boris Beizer] 

276 All-computation-uses strategy. For every variable and every definition of that variable, include at least one definition-free path 
from the definition to every computation use. [«Software Testing Techniques, Second Edition», Boris Beizer] 

277 All-predicate-uses strategy. For every variable and every definition of that variable, include at least опе definition-free path from 
the definition to every predicate use. [«Software Testing Techniques, Second Edition», Boris Beizer] 

278 All-uses strategy. Test set includes at least one path segment from every definition to every use that can be reached by that 
definition. [«Software Testing Techniques, Second Edition», Boris Beizer] 

279 All-DU-path strategy. Test set includes every du path from every definition of every variable to every use of that definition. 
[«Software Testing Techniques, Second Edition», Boris Beizer] 
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Для лучшего понимания и запоминания приведём оригинальную схему из 
книги Бориса Бейзера (там она фигурирует под именем «Figure 5.7. Relative 
Strength of Structural Test Strategies»), показывающую взаимосвязь стратегий 
тестирования на основе потока данных (рисунок 2.3.m). 


All-Paths 


All-DU-Paths 


All-Uses 


All-C-Uses/Some-P-Uses 


All-P-Uses/Some-C-Uses 


All-C-Uses All-Defs All-P-Uses 


Branch 
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Рисунок 2.3.m — Взаимосвязь и относительная мощность стратегий тестирования 
на основе потока данных (по книге Бориса Бейзера «Техники тестирования ПО») 
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2.3.4. Классификация по принадлежности к тестированию по ме- 
тоду белого и чёрного ящиков 


Типичнейшим вопросом на собеседовании для начинающих тестировщиков 
является просьба перечислить техники тестирования по методу белого и чёрного 
ящиков. Ниже представлена таблица 2.3.4, в которой все вышерассмотренные 
виды тестирования соотнесены с соответствующим методом. Эту таблицу можно 
использовать также как справочник по видам тестирования (они представлены в 
той же последовательности, в какой описаны в данной главе). 









Важно! В источниках наподобие І5ТОВ-глоссария многие виды и техники 
‚ тестирования жёстко соотнесены с методами белого или чёрного ящика. | 
‚ Но это не значит, что их невозможно применить в другом, не отмеченном | 
‚ методе. Так, например, тестирование на основе классов эквивалентности | 
‚ отнесено к методу чёрного ящика, но оно прекрасно подходит и для Hann- | 
‚ сания модульных тест-кейсов, являющихся ярчайшими представителями | 
‚ тестирования по методу белого ящика. | 


| Воспринимайте данные из представленной ниже таблицы не как «этот вид | 
тестирования может применяться только для...», а как «чаще всего этот | 
ид тестирования применяется для...» 








Таблица 2.3.а — Виды и техники тестирования в контексте методов белого и чёр- 
НОГО ЯЩИКОВ 





















































Вид тестирования Вид тестирования (англо- Белый ящик | Чёрный ящик 
(русскоязычное название) язычное название) 
Статическое тестирование“! | Static testing Да Нет 
Динамическое тестирова- Dynamic testing Изредка Да 
ние} 
Ручное тестирование? Manual testing Mano Да 
Автоматизированное тести- Automated testing Да Да 
рование{"3} 
Модульное (компонентное) Unit testing, Module testing, Да Нет 
тестирование“! Component testing 
Интеграционное тестирова- Integration testing Да Да 
ние“ 
Системное тестирование?) System testing Mano Да 
Дымовое тестирование!" 8} Smoke test, Intake test, Build Mano Да 
verification test 
Тестирование критического Сийса! раїһ їеѕї Мало Да 
пути?) 
Расширенное тестирова- Extended test Mano Да 
ние!78} 
Позитивное тестирование?) Positive testing Да Да 
Негативное тестирование} Negative testing, Invalid testing Да Да 
Тестирование веб-приложе- Web-applications testing Да Да 
ний(80} 
Тестирование мобильных Mobile applications testing Да Да 
приложений} 
Тестирование настольных Desktop applications testing Да Да 
приложений} 
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ние8} 














Тестирование уровня пред- Presentation tier testing Mano Да 
ставления!80) 

Тестирование уровня бизнес- | Business logic tier testing Да Да 
логики} 

Тестирование уровня дан- Data tier testing Да Мало 
ных{80) 

Альфа-тестирование" Alpha testing Mano Да 
Бета-тестирование Beta testing Почти никогда Да 
Гамма-тестирование{8 Gamma testing Почти никогда Да 
Тестирование на основе тест- | Scripted testing, Test case Да Да 
кейсов" based testing 

Исследовательское тестиро- | Exploratory testing HeT Да 
Bannel? 

Свободное (интуитивное) Te- | Ad hoc testing HeT Да 
стирование"?} 

Функциональное тестирова- Functional testing Да Да 
nnet? 

Нефункциональное тестиро- | Non-functional testing Да Да 
вание} 

Инсталляционное тестирова- | Installation testing Изредка Да 
ние83} 

Регрессионное тестирова- Regression testing Да Да 
ние{8“} 

Повторное тестирование!“ Re-testing, Confirmation testing Да Да 
Приёмочное тестирование“ | Acceptance testing Крайне редко Да 
Операционное тестирова- Operational testing Крайне редко Да 
ние{85} 

Тестирование удобства ис- Usability testing Крайне редко Да 
пользования} 

Тестирование доступности} | Accessibility testing Крайне редко Да 
Тестирование интерфейса} | Interface testing Да Да 
Тестирование безопасно- Security testing Да Да 
сти{86} 

Тестирование интернациона- | Internationalization testing Мало Да 
лизации{86} 

Тестирование локализации} | Localization testing Мало Да 
Тестирование совместимо- Compatibility testing Mano Да 
сти{86} 

Конфигурационное тестиро- Configuration testing Mano Да 
вание} 

Кросс-браузерное тестирова- | Cross-browser testing Мало Да 
ние87} 

Тестирование данных и баз Data quality testing апа Data- Да Мало 
данных} base integrity testing 

Тестирование использования | Resource utilization testing Крайне редко Да 
ресурсов” 

Сравнительное тестирова- Comparison testing HeT Да 
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или таблице состояний“ 














Демонстрационное тестиро- Qualification testing HeT Да 

вание!88} 

Исчерпывающее тестирова- Exhaustive testing Крайне редко Нет 

ние{88} 

Тестирование надёжности} Reliability testing Крайне редко Да 

Тестирование восстанавли- Recoverability testing Крайне редко Да 

ваемости!88) 

Тестирование отказоустойчи- | Failover testing Крайне редко Да 

вости!88) 

Тестирование производи- Performance testing Крайне редко Да 

тельности{88} 

Нагрузочное тестирование 8 | Load testing, Capacity testing Крайне редко Да 

Тестирование масштабируе- | Scalability testing Крайне редко Да 

мости!89) 

Объёмное тестирование} Volume testing Крайне редко Да 

Стрессовое тестирование Stress testing Крайне редко Да 

Конкурентное тестирова- Concurrency testing Крайне редко Да 

ние{89} 

Инвазивное тестирование} Intrusive testing Да Да 

Неинвазивное тестирова- Мопіпігиѕіме testing Да Да 

ние 90} 

Тестирование под управле- Data-driven testing Да Да 

нием данными} 

Тестирование под управле- Кеум/ога-апуеп testing Да Да 

нием ключевыми словами} 

Тестирование предугадыва- Error guessing Крайне редко Да 

нием ошибок?) 

Эвристическая оценка" Heuristic evaluation HeT Да 

Мутационное тестирова- Mutation testing Да Да 

ние} 

Тестирование добавлением Error seeding Да Да 

ошибок?" 

Тестирование на основе Equivalence partitioning Да Да 

классов эквивалентности" 

Тестирование на основе rpa- | Boundary value analysis Да Да 

ничных условий 2} 

Доменное тестирование? ?} Domain testing, Domain analy- Да Да 
$15 

Попарное тестирование? Pairwise testing Да Да 

Тестирование на основе ор- Orthogonal array testing Да Да 

тогональных массивов 2} 

Тестирование в процессе Development testing Да Да 

разработки} 

Тестирование по потоку Control flow testing Да Нет 

управления 3} 

Тестирование по потоку дан- | Data flow testing Да Нет 

ных(93} 

Тестирование по диаграмме State transition testing Изредка Да 
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всех объявлений" 5} 














Инспекция (аудит) кода“? Code review, code inspection Да Нет 
Тестирование на основе Bbl- | Statement testing Да Нет 
ражений“? 

Тестирование на основе вет- | Branch testing Да Нет 
вей 

Тестирование на основе Condition testing Да Нет 
условий} 

Тестирование на основе KOM- | Multiple condition testing Да Нет 
бинаций условий} 

Тестирование на основе от- Modified condition decision Да Нет 
дельных условий, порождаю- | coverage testing 

щих ветвление?) («решаю- 

щих условий») 

Тестирование на основе ре- Decision testing Да Нет 
шений} 

Тестирование на основе пу- Path testing Да Нет 
тей‘э} 

Тестирование по таблице Decision table testing Да Да 
принятия решений} 

Тестирование по моделям Model-based testing Да Да 
поведения приложения} 

Тестирование на основе ва- Use case testing Да Да 
риантов использования} 

Параллельное тестирова- Parallel testing Да Да 
ние!97) 

Тестирование на основе cny- | Random testing Да Да 
чайных данных?” 

А/В-тестирование” А/В testing, Split testing HeT Да 
Восходящее тестирование" | Bottom-up testing Да Да 
Нисходящее тестирование 8} | Top-down testing Да Да 
Гибридное тестирование} Hybrid testing Да Да 
Тестирование на основе де- Classification tree method Да Да 
рева классификаций!“ 

Тестирование на основе син- | Syntax testing Да Да 
таксиса( 04} 

Комбинаторные техники" O4 Combinatorial testing Да Да 
(комбинаторное тестирова- 

ние) 

Тестирование всех комбина- | All combinations testing Да Нет 
ций 04} 

Тестирование с выбором 3Ha- | Each choice testing Да Нет 
чений-представителей! 5“? 

Тестирование с выбором 6a- | Base choice testing Да Нет 
зового набора значений! 

Тестирование по графу при- Саизе-еНес{ graphing Мало Да 
чинно-следственных свя- 

зей(104 

Проверка использования All-definitions testing Да Нет 
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Проверка всех вычислений All-c-uses testing Да Нет 
на основе всех объявле- 
Проверка всех ветвлений на | All-p-uses testing Да Нет 


основе всех объявлений!) 





Проверка всех вычислений и | А|-изез testing Да Нет 
ветвлений на основе всех 
объявлений") 





Проверка использования All-du-paths testing Да Нет 
всех объявлений и всех пу- 

тей без переобъявлений" 3} 
(без циклов или с однократ- 
ными повторениями циклов) 
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2.4. Чек-листы, тест-кейсы, наборы тест-кейсов 


2.4.1. Чек-лист 


Как легко можно понять из предыдущих глав, тестировщику приходится ра- 
ботать с огромным количеством информации, выбирать из множества вариантов 
решения задач и изобретать новые. В процессе этой деятельности объективно не- 
возможно удержать в голове все мысли, а потому продумывание и разработку тест- 
кейсов рекомендуется выполнять с использованием «чек-листов». 





ек-лист (checklist) — набор идей [тест-кейсов]. Последнее слово не зря | 
взято в скобки, т.к. в общем случае чек-лист — это просто набор идей: | 
идей по тестированию, идей по разработке, идей по планированию n- 
равлению — любых идей. | 





Чек-лист чаще всего представляет собой обычный и привычный нам список: 

• в котором последовательность пунктов не имеет значения (например, список 
значений некоего поля); 

• в котором последовательность пунктов важна (например, шаги в краткой nH- 
струкции); 

e структурированный (многоуровневый) список, который позволяет отразить 
иерархию идей. 


Важно понять, что нет и не может быть никаких запретов и ограничений при 
разработке чек-листов — главное, чтобы они помогали в работе. Иногда чек-листы 
могут даже выражаться графически (например, с использованием ментальных 
карт? или концепт-карт?8з), хотя традиционно их составляют в виде многоуровне- 
ВЫХ списков. 

Поскольку в разных проектах встречаются однотипные задачи, хорошо про- 
думанные и аккуратно оформленные чек-листы могут использоваться повторно, 
чем достигается экономия сил и времени. 





нимание! Очень частым является вопрос о том, нужно ли в чек-листах _ 
писать ожидаемые результаты. В классическом понимании чек-листа — | 
‚ нет (хоть это и не запрещено), т.к. чек-лист — это набор идей, а их детали- | 
‚ зация в виде шагов и ожидаемых результатов будет в тест-кейсах. Но ожи- | 
 даемые результаты могут добавляться, например, в следующих случаях: | 
e в некоем пункте чек-листа рассматривается особое, нетривиальное NO- , 
’ ведение приложения или сложная проверка, результат которой важно · 
‚ отметить уже сейчас, чтобы не забыть; 
е в силу сжатых сроков и/или нехватки иных ресурсов тестирование npo- | 











280 Понятие «чек-листа» не завязано на тестировании как таковом — это совершенно универсальная техника, которая может 
применяться в любой без исключения области жизни. В русском языке вне контекста информационных технологий чаще 
используется понятное и привычное слово «список» (например, «список покупок», «список дел» и т.д.), но в тестирова- 
нии прижилась калькированная с английского версия — «чек-лист». 

Если у вас возник вопрос «почему тут использованы квадратные скобки», ознакомьтесь с синтаксисом «расширенной 
формы Бэкуса-Наура», который де-факто является стандартом описания выражений в ИТ. См. «Extended Васки$—Маиг 
form», Wikipedia. [ћїрѕ://еп.мікіреаіа.огд^мікі/Ехіепаеа Васкиѕ%Е2%80%93М№аиг огт] 

282 «Mind тар», Wikipedia. [http://en.wikipedia.org/wiki/Mind тар] 

283 «Concept тар», Wikipedia. [http://en.wikipedia.org/wiki/Concept_map] 


281 
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Для того чтобы чек-лист был действительно полезным инструментом, он дол- 
жен обладать рядом важных свойств. 


Логичность. Чек-лист пишется не «просто так», а на основе целей и для того, 
чтобы помочь в достижении этих целей. К сожалению, одной из самых частых и 
опасных ошибок при составлении чек-листа является превращение его в свалку 
мыслей, которые никак не связаны друг с другом. 


Последовательность и структурированность. Со структурированностью 
всё достаточно просто — она достигается за счёт оформления чек-листа в виде 
многоуровневого списка. Что до последовательности, то даже в том случае, когда 
пункты чек-листа не описывают цепочку действий, человеку всё равно удобнее вос- 
принимать информацию в виде неких небольших групп идей, переход между кото- 
рыми является понятным и очевидным (например, сначала можно прописать идеи 
простых позитивных тест-кейсов”°, потом идеи простых негативных тест-кейсов, 
потом постепенно повышать сложность тест-кейсов, но не стоит писать эти идеи 
вперемешку). 


Полнота и неизбыточность. Чек-лист должен представлять собой аккурат- 
ную «сухую выжимку» идей, в которых нет дублирования (часто появляется из-за 
разных формулировок одной и той же идеи), и в то же время ничто важное не упу- 
щено. 


Правильно создавать и оформлять чек-листы также помогает восприятие их 
не только как хранилища наборов идей, но и как «требования для составления тест- 
кейсов». Эта мысль приводит к пересмотру и переосмыслению свойств качествен- 
ных требований (см. главу «Свойства качественных требований» “!) в применении 
к чек-листам. 





Задание 2.4.а: перечитайте главу «Свойства качественных требова- | 
ний» и подумайте, какие свойства качественных требований можно 7 
‚ также считать и свойствами качественных чек-листов. | 








Итак, рассмотрим процесс создания чек-листа. В главе «Пример анализа и 
тестирования требований» приведён пример итоговой версии требований”, KO- 
торый мы и будем использовать. 

Поскольку мы не можем сразу «протестировать всё приложение» (это слиш- 
ком большая задача, чтобы решить её одним махом), нам уже сейчас нужно вы- 
брать некую логику построения чек-листов — да, их будет несколько (в итоге их 
можно будет структурированно объединить в один, но это не обязательно). 

Типичными вариантами такой логики является создание отдельных чек-ли- 
стов для: 

e типичных пользовательских сценариев“; 
различных уровней функционального тестирования; 
отдельных частей (модулей и подмодулей! 22) приложения; 
отдельных требований, групп требований, уровней и типов требований; 
частей или функций приложения, наиболее подверженных рискам. 


Этот список можно расширять и дополнять, можно комбинировать его 
пункты, получая, например, чек-листы для проверки наиболее типичных сценариев, 
затрагивающих некую часть приложения. 

Чтобы проиллюстрировать принципы построения чек-листов, мы воспользу- 
емся логикой разбиения функций приложения по степени их важности на три кате- 
гории (см. классификацию по убыванию степени важности функций приложения”): 
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Базовые функции, без которых существование приложения теряет смысл 
(т.е. самые важные — то, ради чего приложение вообще создавалось), или 
нарушение работы которых создаёт объективные серьёзные проблемы для 
среды исполнения. (См. «Дымовое тестирование» "°). 
Функции, востребованные большинством пользователей в их повседневной 
работе. (См. «Тестирование критического пути»?”). 
Остальные функции (разнообразные «мелочи», проблемы с которыми не 
сильно повлияют на ценность приложения для конечного пользователя). (См. 
«Расширенное тестирование»). 


Функции, без которых существование приложения теряет смысл 


Сначала приведём целиком весь чек-лист для дымового тестирования, а по- 
том разберём его подробнее. 


Конфигурирование и запуск. 


Обработка файлов: 



































Форматы входных файлов 
TXT HTML MD 
Кодировки WIN1251 + + + 
входных фай- | CP866 + + + 
лов КОЗА + + + 
• Остановка. 


Да, и всё. Здесь перечислены все ключевые функции приложения. 


Конфигурирование и запуск. Если приложение невозможно настроить для 
работы в пользовательской среде, оно бесполезно. Если приложение не запуска- 
ется, оно бесполезно. Если на стадии запуска возникают проблемы, они могут нега- 
тивно отразиться на функционировании приложения и потому также заслуживают 
пристального внимания. 

Примечание: в нашем примере мы столкнулись со скорее нетипичным слу- 
чаем — приложение конфигурируется параметрами командной строки, а потому 
разделить операции «конфигурирования» и «запуска» не представляется возмож- 
ным; в реальной жизни для подавляющего большинства приложений эти операции 
выполняются раздельно. 


Обработка файлов. Ради этого приложение и разрабатывалось, потому 
здесь даже на стадии создания чек-листа мы не поленились создать матрицу, от- 
ражающую все возможные комбинации допустимых форматов и допустимых коди- 
ровок входных файлов, чтобы ничего не забыть и подчеркнуть важность соответ- 
ствующих проверок. 


Остановка. С точки зрения пользователя эта функция может не казаться 
столь уж важной, но остановка (и запуск) любого приложения связаны с большим 
количеством системных операций, проблемы с которыми могут привести к множе- 
ству серьёзных последствий (вплоть до невозможности повторного запуска прило- 
жения или нарушения работы операционной системы). 


Функции, востребованные большинством пользователей 


Следующим шагом мы будем выполнять проверку того, как приложение ве- 
дёт себя в обычной повседневной жизни, пока не затрагивая экзотические ситуа- 
ции. Очень частым вопросом является допустимость дублирования проверок на 
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разных уровнях функционального тестирования" — можно ли так делать. Одно- 
временно и «нет», и «да». «Нет» в том смысле, что не допускается (не имеет 
смысла) повторение тех же проверок, которые только что были выполнены. «Да» в 
том смысле, что любую проверку можно детализировать и снабдить дополнитель- 


ными деталями. 


• Конфигурирование и запуск: 
о С верными параметрами: 


Значения SOURCE ВІК, ОЕЅТІМАТІОМ ВІК, ГОС ЕЕ МАМЕ 
указаны и содержат пробелы и кириллические символы (повто- 
рить для форматов путей в Windows и *піх файловых системах, 
обратить внимание на имена логических дисков и разделители 
имён каталогов (“P и “\”)). 

Значение LOG_FILE_NAME не указано. 


о Без параметров. 
о С недостаточным количеством параметров. 
о С неверными параметрами: 


Недопустимый путь SOURCE_DIR. 

Недопустимый путь DESTINATION_DIR. 

Недопустимое имя ОС ЕЕ МАМЕ. 

РЕЅТІМАТІОМ ВІА находится внутри SOURCE_DIR. 
Значения ОЕЅТІМАТІОМ РІА и SOURCE_DIR совпадают. 


• Обработка файлов: 
о Разные форматы, кодировки и размеры: 



































Форматы входных файлов 
TXT HTML MD 
Кодировки | WIN1251 100 KB 50 MB 10 MB 
входных фай- | CP866 10 МБ 100 КБ 50 МБ 
лов KOI8R 50 MB 10 MB 100 KB 
Любая 0 байт 
Любая 50 МБ +1Б 50 МБ +1Б 50 МБ +1Б 
- Любой недопустимый формат 
Любая Повреждения в допустимом формате 














о Недоступные входные файлы: 
= Нет прав доступа. 
" Файл открыт и заблокирован. 
= Файл с атрибутом «только для чтения». 
Остановка: 
о Закрытием окна консоли. 
Журнал работы приложения: 
о Автоматическое создание (при отсутствии журнала). 
о Продолжение (дополнение журнала) при повторных запусках. 
Производительность: 
о Элементарный тест с грубой оценкой. 


Обратите внимание, что чек-лист может содержать не только «предельно 


сжатые тезисы», но и вполне развернутые комментарии, если это необходимо — 
лучше пояснить суть идеи подробнее, чем потом гадать, что же имелось в виду. 


Также обратите внимание, что многие пункты чек-листа носят весьма высо- 


коуровневый характер, и это нормально. Например, «повреждения в допустимом 
формате» (см. матрицу с кодировками, форматами и размерами) звучит расплыв- 
чато, но этот недочёт будет устранён уже на уровне полноценных тест-кейсов. 
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Остальные функции и особые сценарии 


Пришло время обратить внимание на разнообразные мелочи и хитрые ню- 
ансы, проблемы с которыми едва ли сильно озаботят пользователя, но формально 
всё же будут считать ошибками. 


• Конфигурирование и запуск: 
о Значения ЗОЧАСЕ_ DIR, ОЕЗТИМАТЮМ ГА, ГОО ЕЕ МАМЕ: 
= В разных стилях (Windows-nytn + *пїх-пути) — одно в одном 
стиле, другое — в другом. 
= С использованием УМС-имён. 
" ОС ЕЕ МАМЕ внутри ЗОЧАСЕ_ ГВ. 
" ОС ЕП Е МАМЕ внутри ОЕЅТІМАТІОМ РІВ. 
о Размер 106 ЕЕ МАМЕ на момент запуска: 
= 2—4 ГБ. 
" 4+ ГБ. 
о Запуск двух и более копий приложения с: 
= Одинаковыми параметрами ЗОУЧВАСЕ_ DIR, ОЕЗТИМАТЮМ ОВ, 
LOG_FILE_NAME. 
= Одинаковыми SOURCE_DIR и LOG_FILE_NAME, но разными 
РОЕЅТІМАТІОМ ВІА. 
= Одинаковыми ОЕЅТІМАТІОМ ВІВ и 106 ЕЕ МАМЕ, но раз- 
ными SOURCE_DIR. 
• Обработка файлов: 
о Файл верного формата, в котором текст представлен в двух и более 
поддерживаемых кодировках одновременно. 
о Размер входного файла: 
= 2—4 ГБ. 
" 4+ ГБ. 


© Задание 2.4.6: возможно, вам захотелось что-то изменить в приведённы 

| выше чек-листах — это совершенно нормально и справедливо: нет и не 
‚ может быть некоего «единственно верного идеального чек-листа», и ваши 
идеи вполне имеют право на существование, потому составьте свой соб 

‚ ственный чек-лист или отметьте недостатки, которые вы заметили в при 

едённом выше чек-листе. 














Как мы увидим в следующей главе, создание качественного тест-кейса может 
потребовать длительной кропотливой и достаточно монотонной работы, которая 
при этом не требует от опытного тестировщика сильных интеллектуальных усилий, 
а потому переключение между работой над чек-листами (творческая составляю- 
щая) и расписыванием их в тест-кейсы (механическая составляющая) позволяет 
разнообразить рабочий процесс и снизить утомляемость. Хотя, конечно, написание 
сложных и притом качественных тест-кейсов может оказаться ничуть не менее 
творческой работой, чем продумывание чек-листов. 
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2.4.2. Тест-кейс и его жизненный цикл 


Терминология и общие сведения 


Для начала определимся с терминологией, поскольку здесь есть много пута- 
ницы, вызванной разными переводами англоязычных терминов на русский язык и 
разными традициями в тех или иных странах, фирмах и отдельных командах. 

Во главе всего лежит термин «тест». Официальное определение звучит так. 


п Тест (test) — набор из одного или нескольких тест-кейсов. 





Поскольку среди всех прочих терминов этот легче и быстрее всего произно- 
сить, в зависимости от контекста под ним могут понимать и отдельный пункт чек- 
листа, и отдельный шаг в тест-кейсе, и сам тест-кейс, и набор тест-кейсов и... про- 
должать можно долго. Главное здесь одно: если вы слышите или видите слово 
«тест», воспринимайте его в контексте. 


Теперь рассмотрим самый главный для нас термин — «тест-кейс». 





 Тест-кейс (test case?) — набор входных данных, условий выполнения и | 
ожидаемых результатов, разработанный с целью проверки того или иного _ 
‚ свойства или поведения программного средства. | 


Под тест- -кейсом также может пониматься а аи документ, 





Мы ещё вернёмся к этой мысли!'*, но уже сейчас критически важно понять и 
запомнить: если у тест-кейса не указаны входные данные, условия выполнения и 
ожидаемые результаты, и/или не ясна цель тест-кейса — это плохой тест-кейс (ино- 
гда он не имеет смысла, иногда его и вовсе невозможно выполнить). 

Примечание: иногда термин «test case» на русский язык переводят как «те- 
стовый случай». Это вполне адекватный перевод, но из-за того, что «тест-кейс» ко- 
paie произносить, наибольшее распространение получил именно этот вариант. 





стальные термины, связанные с тестами, тест-кейсами и тестовыми CUE- 
‚ нариями, на данном этапе можно прочитать просто в ознакомительных UE- 
лях. Если вы откроете І$ТОВ-глоссарий на букву «Т», вы увидите огром- | 
‚ ное количество терминов, тесно связанных друг с другом перекрёстными | 
ссылками: на начальном этапе изучения тестирования нет необходимости | 
глубоко рассматривать их все, однако некоторые всё же заслуживают вни- ' 





ания. Они представлены ниже. 





Высокоуровневый тест-кейс (high level test сазе?) — тест-кейс без KOH- 
кретных входных данных и ожидаемых результатов. 

Как правило, ограничивается общими идеями и операциями, схож по своей 
сути с подробно описанным пунктом чек-листа. Достаточно часто встречается в ин- 
теграционном тестировании?* и системном тестировании, а также на уровне Abl- 
мового тестирования". Может служить отправной точкой для проведения исследо- 
вательского тестирования? или для создания низкоуровневых тест-кейсов. 





284 Test. А set ої one ог тоге test cases. [ISTQB Glossary] 

285 Test case. A set of input values, execution preconditions, expected results and execution postconditions, developed for a particular 
objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement. 
[ISTQB Glossary] 

286 High level test case (logical test case). A test case without concrete (implementation level) values for input data and expected 
results. Logical operators are used; instances of the actual values are not yet defined and/or available. [ISTQB Glossary] 
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Низкоуровневый тест-кейс (low level test сасе®”) — тест-кейс с конкретными 
входными данными и ожидаемыми результатами. 

Представляет собой «полностью готовый к выполнению» тест-кейс и вообще 
является наиболее классическим видом тест-кейсов. Начинающих тестировщиков 
чаще всего учат писать именно такие тесты, т.к. прописать все данные подробно — 
намного проще, чем понять, какой информацией можно пренебречь, при этом не 
снизив ценность тест-кейса. 


Спецификация тест-кейса (test case specification?8) — документ, описываю- 
щий набор тест-кейсов (включая их цели, входные данные, условия и шаги выпол- 
нения, ожидаемые результаты) для тестируемого элемента (test іїет289, test ob- 
јесігәо). 


Спецификация теста (test specification??) — документ, состоящий из специ- 
фикации тест-дизайна (test design ѕресійсайоп2°), спецификации тест-кейса (test 
case ѕресійсаііоп28) и/или спецификации тест-процедуры (test procedure specifica- 
101293). 

Тест-сценарий (test ѕсепагіо2%, test procedure specification, test script) — go- 


кумент, описывающий последовательность действий по выполнению теста (также 
известен как «тест-скрипт»). 





‚ Внимание! Из-за особенностей перевода очень часто под термином «тест- ' 
сценарий» («тестовый сценарий») имеют в виду набор тест-кейсов““з. 





Цель написания тест-кейсов 


Тестирование можно проводить и без тест-кейсов (не нужно, но можно; да, 
эффективность такого подхода варьируется в очень широком диапазоне в зависи- 
мости от множества факторов). Наличие же тест-кейсов позволяет: 

e Структурировать и систематизировать подход к тестированию (без чего круп- 
ный проект почти гарантированно обречён на провал). 

e Вычислять метрики тестового покрытия (test coverage? metrics) и принимать 
меры по его увеличению (тест-кейсы здесь являются главным источником 
информации, без которого существование подобных метрик теряет смысл). 

• Отслеживать соответствие текущей ситуации плану (сколько примерно пона- 
добится тест-кейсов, сколько уже есть, сколько выполнено из запланирован- 
ного на данном этапе количества и т.д.). 

• Уточнить взаимопонимание между заказчиком, разработчиками и тестиров- 





287 Low level test case. А test case with concrete (implementation level) values for input data апа expected results. Logical operators 
from high level test cases are replaced by actual values that correspond to the objectives of the logical operators. [ISTQB Glos- 
sary] 

288 Test case specification. A document specifying a set of test cases (objective, inputs, test actions, expected results, and execution 
preconditions) for a test item. [ISTQB Glossary] 

289 Test item. The individual element to be tested. There usually is one test object and many test items. [ISTQB Glossary] 

290 Test object. The component or system to be tested. [ISTQB Glossary] 

291 Test specification. A document that consists of a test design specification, test case specification and/or test procedure specifi- 
cation. [ISTQB Glossary] 

292 Test design specification. A document specifying the test conditions (coverage items) for a test item, the detailed test approach 
and identifying the associated high level test cases. [ISTQB Glossary] 

293 Test procedure specification (test procedure). A document specifying a sequence of actions for the execution of a test. Also 
known as test script or manual test script. [ISTQB Glossary] 

294 Test scenario. A document specifying a sequence of actions for the execution of a test. Also known as test script or manual test 
script. [ISTQB Glossary] 

295 Coverage (test coverage). The degree, expressed as a percentage, to which a specified coverage item (an entity or property 
used as a basis for test coverage, e.g. equivalence partitions or code statements) has been exercised by a test suite. [ISTQB 
Glossary] 





Тестирование программного обеспечения. Базовый курс. © ЕРАМ Systems, 2015-2021 Стр: 118/298 


Тест-кейс и его жизненный цикл 





щиками (тест-кейсы зачастую намного более наглядно показывают поведе- 
ние приложения, чем это отражено в требованиях). 

e Хранить информацию для длительного использования и обмена опытом 
между сотрудниками и командами (или как минимум — не пытаться удержать 
в голове сотни страниц текста). 

e Проводить регрессионное тестирование“ и повторное тестирование (ко- 
торые без тест-кейсов было бы вообще невозможно выполнить). 

• Повышать качество требований (мы это уже рассматривали: написание чек- 
листов и тест-кейсов — хорошая техника тестирования требований“). 

• Быстро вводить в курс дела нового сотрудника, недавно подключившегося к 
проекту. 


Жизненный цикл тест-кейса 


В отличие от отчёта о дефекте, у которого есть полноценный развитый жиз- 
ненный циклй57, для тест-кейса речь скорее идёт о наборе состояний (см. рисунок 
2.4.а), в которых он может находиться (жирным шрифтом отмечены наиболее важ- 
ные состояния). 
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Рисунок 2.4.а — Жизненный цикл (набор состояний) тест-кейса 


2 


e Создан (пем) — типичное начальное состояние практически любого арте- 
факта. Тест-кейс автоматически переходит в это состояние после создания. 

e Запланирован (planned, ready for testing) — в этом состоянии тест-кейс нахо- 
дится, когда он или явно включён в план ближайшей итерации тестирования, 
или как минимум готов для выполнения. 
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e Не выполнен (по tested) — в некоторых системах управления тест-кейсами 
это состояние заменяет собой предыдущее («запланирован»). Нахождение 
тест-кейса в данном состоянии означает, что он готов к выполнению, но ещё 
не был выполнен. 

e Выполняется (work іп progress) — если тест-кейс требует длительного вре- 
мени на выполнение, он может быть переведён в это состояние для подчёр- 
кивания того факта, что работа идёт, и скоро можно ожидать её результатов. 
Если выполнение тест-кейса занимает мало времени, это состояние, как пра- 
вило, пропускается, а тест-кейс сразу переводится в одно из трёх следующих 
состояний — «провален», «пройден успешно» или «заблокирован». 

e Пропущен (skipped) — бывают ситуации, когда выполнение тест-кейса oT- 
меняется по соображениям нехватки времени или изменения логики тести- 
рования. 

e Провален (failed) — данное состояние означает, что в процессе выполнения 
тест-кейса был обнаружен дефект, заключающийся в том, что ожидаемый 
результат по как минимум одному шагу тест-кейса не совпадает с фактиче- 
ским результатом. Если в процессе выполнения тест-кейса был «случайно» 
обнаружен дефект, никак не связанный с шагами тест-кейса и их ожидае- 
мыми результатами, тест-кейс считается пройденным успешно (при этом, 
естественно, по обнаруженному дефекту создаётся отчёт о дефекте). 

e Пройден успешно (passed) — данное состояние означает, что в процессе 
выполнения тест-кейса не было обнаружено дефектов, связанных с расхож- 
дением ожидаемых и фактических результатов его шагов. 

e Заблокирован (blocked) — данное состояние означает, что по какой-то Npn- 
чине выполнение тест-кейса невозможно (как правило, такой причиной явля- 
ется наличие дефекта, не позволяющего реализовать некий пользователь- 
ский сценарий). 

e Закрыт (closed) — очень редкий случай, т.к. тест-кейс, как правило, остав- 
ляют в состояниях «провален / пройден успешно / заблокирован / пропущен». 
В данное состояние в некоторых системах управления тест-кейс переводят, 
чтобы подчеркнуть тот факт, что на данной итерации тестирования все дей- 
ствия с ним завершены. 

• Требует доработки (пої геаду) — как видно из схемы, в это состояние (и из 
него) тест-кейс может быть переведён в любой момент времени, если в нём 
будет обнаружена ошибка, если изменятся требования, по которым он был 
написан, или наступит иная ситуация, не позволяющая считать тест-кейс 
пригодным для выполнения и перевода в иные состояния. 


Ещё раз подчеркнём, что в отличие от жизненного цикла дефекта, который 
достаточно стандартизирован и формализован, для тест-кейса описанное выше но- 
сит общий рекомендательный характер, рассматривается скорее как разрозненный 
набор состояний (а не строгий жизненный цикл) и может сильно отличаться в раз- 
ных компаниях (в связи с имеющимися традициями и/или возможностями систем 
управления тест-кейсами). 
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2.4.3. Атрибуты (поля) тест-кейса 


Как уже было сказано выше, термин «тест-кейс» может относиться к фор- 
мальной записи тест-кейса в виде технического документа. Эта запись имеет об- 
щепринятую структуру, компоненты которой называются атрибутами (полями) тест- 
кейса. 

В зависимости от инструмента управления тест-кейсами внешний вид их за- 
писи может немного отличаться, могут быть добавлены или убраны отдельные 


поля, но концепция остаётся неизменной. 
Общий вид всей структуры тест-кейса представлен на рисунке 2.4.5. 










Приоритет 





Иденти- 
фикатор 






Связанное с тест-кейсом требование 






Заглавие (суть) тест-кейса 


Ожидаемый результат по 
каждому шагу тест-кейса 
















Панель 
ле- загрузки 






Модуль и подмо- 
дуль приложения 











Исходные данные, не- 
обходимые для выпол- 
нения тест-кейса 





Загрузка картинки (имя 
со спецсимволами) 

Приготовления: создать 
непустой файл с именем 


. Выбрать вкладку «За- 
грузить». 

2. Нажать кнопку «Вы- 
брать». 

8. Выбрать из списка 
приготовленный файл. 
4. Нажать кнопку «ОК». 
5. Нажать кнопку «Доба- 
вить в галерею». 


1. Вкладка «Загрузить» 
становится активной. 
2. Появляется диалого- 
вое окно браузера вы- 
бора файла для за- 
грузки. 

3. Имя выбранного 
файла появляется в 
поле «Файл». 

4. Диалоговое окно 
файла закрывается, в 
поле «Файл» появля- 
ется полное имя 
файла. 


5. Выбранный файл 
появляется в списке 
файлов галереи. 


Шаги тест-кейса 




















Рисунок 2.4.6 — Общий вид тест-кейса 


Теперь рассмотрим каждый атрибут подробно. 


Идентификатор (identifier) представляет собой уникальное значение, позво- 
ляющее однозначно отличить один тест-кейс от другого и используемое во всевоз- 
можных ссылках. В общем случае идентификатор тест-кейса может представлять 
собой просто уникальный номер, но (если позволяет инструментальное средство 
управления тест-кейсами) может быть и куда сложнее: включать префиксы, суф- 
фиксы и иные осмысленные компоненты, позволяющие быстро определить цель 
тест-кейса и часть приложения (или требований), к которой он относится (например: 
ОА216 512 Ов Мед). 


Приоритет (priority) показывает важность тест-кейса. Он может быть выра- 
жен буквами (А, В, С, О, Е), цифрами (1, 2, 3, 4, 5), словами («крайне высокий», 
«высокий», «средний», «низкий», «крайне низкий») или иным удобным способом. 
Количество градаций также не фиксировано, но чаще всего лежит в диапазоне от 
трёх до пяти. 

Приоритет тест-кейса может коррелировать с: 

• важностью требования, пользовательского сценария!" или функции, с KOTO- 
рыми связан тест-кейс; 

e потенциальной важностью дефекта!”, на поиск которого направлен тест- 
кейс; 
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e степенью риска, связанного с проверяемым тест-кейсом требованием, сце- 
нарием или функцией. 

Основная задача этого атрибута — упрощение распределения внимания и 
усилий команды (более высокоприоритетные тест-кейсы получают их больше), а 
также упрощение планирования и принятия решения о том, чем можно пожертво- 
вать в некоей форс-мажорной ситуации, не позволяющей выполнить все заплани- 
рованные тест-кейсы. 


Связанное с тест-кейсом требование (requirement) показывает то основное 
требование, проверке выполнения которого посвящён тест-кейс (основное — NO- 
тому, что один тест-кейс может затрагивать несколько требований). Наличие этого 
поля улучшает такое свойство тест-кейса, как прослеживаемость““9. 

Частые вопросы, связанные с заполнением этого поля, таковы: 

• Можно ли его оставить пустым? Да. Тест-кейс вполне мог разрабатываться 
вне прямой привязки к требованиям, и (пока?) значение этого поля опреде- 
лить сложно. Хоть такой вариант и не считается хорошим, он достаточно рас- 
пространен. 

• Можно ли в этом поле указывать несколько требований? Да, но чаще всего 
стараются выбрать одно самое главное или «более высокоуровневое» 
(например, вместо того, чтобы перечислять R56.1, В56.2, 56.3 и т.д., можно 
просто написать Н56). Чаще всего в инструментах управления тестами это 
поле представляет собой выпадающий список, где можно выбрать только 
одно значение, и этот вопрос становится неактуальным. К тому же многие 
тест-кейсы всё же направлены на проверку строго одного требования, и для 
них этот вопрос также неактуален. 


Модуль и подмодуль приложения (module апа submodule) указывают на 
части приложения, к которым относится тест-кейс, и позволяют лучше понять его 
цель. 

Идея деления приложения на модули и подмодули проистекает из того, что 
в сложных системах практически невозможно охватить взглядом весь проект цели- 
ком, и вопрос «как протестировать это приложение» становится недопустимо слож- 
ным. Тогда приложение логически разделяется на компоненты (модули), а те, в 
свою очередь, на более мелкие компоненты (подмодули). И вот уже для таких не- 
больших частей приложения придумать чек-листы и создать хорошие тест-кейсы 
становится намного проще. 

Как правило, иерархия модулей и подмодулей создаётся как единый набор 
для всей проектной команды, чтобы исключить путаницу из-за того, что разные 
люди будут использовать разные подходы к такому разделению или даже просто 
разные названия одних и тех же частей приложения. 

Теперь — самое сложное: как выбираются модули и подмодули. В реально- 
сти проще всего отталкиваться от архитектуры и дизайна приложения. Например, 
в уже знакомом нам приложении? можно выделить такую иерархию модулей и под- 
модулей: 


e Механизм запуска: 
о механизм анализа параметров; 
о механизм сборки приложения; 
о механизм обработки ошибочных ситуаций. 
• Механизм взаимодействия с файловой системой: 
о механизм обхода дерева ЗОУРСЕ ГВ; 
о механизм обработки ошибочных ситуаций. 
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e Механизм преобразования файлов: 

о механизм определения кодировок; 

о механизм преобразования кодировок; 

о механизм обработки ошибочных ситуаций. 
• Механизм ведения журнала: 

о механизм записи журнала; 

о механизм отображения журнала в консоли; 

о механизм обработки ошибочных ситуаций. 


Согласитесь, что такие длинные названия с постоянно повторяющимся сло- 
вом «механизм» читать и запоминать сложно. Перепишем: 


e Стартер: 
о анализатор параметров; 
о сборщик приложения; 
о обработчик ошибок. 
e Сканер: 
о обходчик; 
о обработчик ошибок. 
• Преобразователь: 
о детектор; 
о конвертер; 
о обработчик ошибок. 
• Регистратор: 
о дисковый регистратор; 
о консольный регистратор; 
о обработчик ошибок. 


Но что делать, если мы не знаем «внутренностей» приложения (или не очень 
разбираемся в программировании)? Модули и подмодули можно выделять на ос- 
нове графического интерфейса пользователя (крупные области и элементы внутри 
них), на основе решаемых приложением задач и подзадач ит.д. Главное, чтобы эта 
логика была одинаковым образом применена ко всему приложению. 


Внимание! Частая ошибка! Модуль и подмодуль приложения — это HE 
| действия, это именно структурные части, «куски» приложения. В заблуж- | 
‚ дение вас могут ввести такие названия, как, например, «печать, настройка | 
‚ принтера» (но здесь имеются в виду именно части приложения, отвечаю- | 
щие за печать и за настройку принтера (и названы они отглагольными CY- | 
‚ ществительными), а не процесс печати или настройки принтера). | 


| Сравните (на примере человека): «дыхательная система, лёгкие» — это | 
модуль и подмодуль, а «дыхание», «сопение», «чихание» — нет; «голова, 





Наличие полей «Модуль» и «Подмодуль» улучшает такое свойство тест- 
кейса, как прослеживаемость"0. 
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Заглавие (суть) тест-кейса (title) призвано упростить и ускорить понимание 
основной идеи (цели) тест-кейса без обращения к его остальным атрибутам. 
Именно это поле является наиболее информативным при просмотре списка тест- 
кейсов. 




















Сравните. 
Плохо Хорошо 
Тест 1 Запуск, одна копия, верные параметры 
Тест 2 Запуск одной копии с неверными путями 
Тест 78 (улучшенный) Запуск, много копий, без конфликтов 
Остановка Остановка по Ctrl+C 
Закрытие Остановка закрытием консоли 

















Заглавие тест-кейса может быть полноценным предложением, фразой, набо- 
ром словосочетаний — главное, чтобы выполнялись следующие условия: 
• Информативность. 
• Хотя бы относительная уникальность (чтобы не путать разные тест-кейсы). 





| нимание! Частая ошибка! Если инструмент управления тест-кейсами не 
требует писать заглавие, его всё равно надо писать. Тест-кейсы без за- | 
 главий превращаются в мешанину информации, использование которой. 
пряжено с колоссальными и совершенно бессмысленными затратами 





И ещё одна небольшая мысль, которая может помочь лучше формулировать 
заглавия. В дословном переводе с английского «test case» обозначает «тестовый 
случай (ситуация)». Так вот, заглавие как раз и описывает этот случай (ситуацию), 
т.е. что происходит в тест-кейсе, какую ситуацию он проверяет. 


Исходные данные, необходимые для выполнения тест-кейса 
(precondition, preparation, initial data, setup), позволяют описать всё то, что должно 
быть подготовлено до начала выполнения тест-кейса, например: 

e Состояние базы данных. 
• Состояние файловой системы и её объектов. 
e Состояние серверов и сетевой инфраструктуры. 


То, что описывается в этом поле, готовится БЕЗ использования тестируемого 
приложения, и таким образом, если здесь возникают проблемы, нельзя писать от- 
чёт о дефекте в приложении. Эта мысль очень и очень важна, потому поясним её 
простым жизненным примером. Представьте, что вы дегустируете конфеты. В поле 
«исходные данные» можно прописать «купить конфеты таких-то сортов в таком-то 
количестве». Если таких конфет нет в продаже, если закрыт магазин, если не хва- 
тило денег и т.д. — всё это НЕ проблемы вкуса конфет, и нельзя писать отчёт о 
о конфет вида «конфеты невкусные потому, что закрыт магазин». 





Некоторые авторы не следуют этой логике и допускают в разделе «приго- 


‚ товления» работу с тестируемым приложением. И здесь нет «правильного _ 
варианта» — просто в одной традиции решено одним образом, в другой — | 
другим. Во многом это — ещё и терминологическая проблема: 
«preparation», «initial data» и «setup» вполне логично выполнять без yya- 
‚ стия тестируемого приложения, B то время Kak «precondition» по смыслу | 
‚ ближе к описанию состояния тестируемого приложения. В реальной рабо- 
‚ чей обстановке вам достаточно будет прочитать несколько тест-кейсов, | 
уже созданных вашими коллегами, чтобы понять, какой точки зрения на 
_ данный вопрос они придерживаются. 
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Шаги тест-кейса (steps) описывают последовательность действий, которые 


необходимо реализовать в процессе выполнения тест-кейса. Общие рекомендации 
по написанию шагов таковы: 


начинайте с понятного и очевидного места, не пишите лишних начальных 
шагов (запуск приложения, очевидные операции с интерфейсом и т.п.); 
даже если в тест-кейсе всего один шаг, нумеруйте его (иначе возрастает ве- 
роятность в будущем случайно «приклеить» описание этого шага к новому 
тексту); 

если вы пишете на русском языке, используйте безличную форму (например, 
«открыть», «ввести», «добавить» вместо «откройте», «введите», «до- 
бавьте»), в английском языке не надо использовать частицу «to» (т.е. «запу- 
стить приложение» будет «start application», не «to start application»); 
соотносите степень детализации шагов и их параметров с целью тест-кейса, 
его сложностью, уровнем” и т.д. — в зависимости от этих и многих других 
факторов степень детализации может варьироваться от общих идей до пре- 
дельно чётко прописанных значений и указаний; 

ссылайтесь на предыдущие шаги и их диапазоны для сокращения объёма 
текста (например, «повторить шаги 3—5 со значением...»); 

пишите шаги последовательно, без условных конструкций вида «если... 
ТО...». 


нимание! Частая ошибка! Категорически запрещено ссылаться на шаги | 





‚ из других тест-кейсов и другие тест-кейсы целиком: если те, другие тест- 
_ кейсы будут изменены или удалены, ваш тест-кейс начнёт ссылаться на | 
[ неверные данные или в пустоту, а если в процессе выполнения те, другие 
‚ тест-кейсы или шаги приведут к возникновению ошибки, вы не сможете · 





Ожидаемые результаты (expected results) по каждому шагу тест-кейса onn- 


сывают реакцию приложения на действия, описанные в поле «шаги тест-кейса». 
Номер шага соответствует номеру результата. 


По написанию ожидаемых результатов можно порекомендовать следующее: 
описывайте поведение системы так, чтобы исключить субъективное толкова- 
ние (например, «приложение работает верно» — плохо, «появляется окно с 
надписью...» — хорошо); 

пишите ожидаемый результат по всем шагам без исключения, если у вас есть 
хоть малейшие сомнения в том, что результат некоего шага будет совер- 
шенно тривиальным и очевидным (если вы всё же пропускаете ожидаемый 
результат для какого-то тривиального действия, лучше оставить в списке 
ожидаемых результатов пустую строку — это облегчает восприятие); 
пишите кратко, но не в ущерб информативности; 

избегайте условных конструкций вида «если... то...». 


нимание! Частая ошибка! В ожидаемых результатах ВСЕГДА описыва- | 





ется КОРРЕКТНАЯ работа приложения. Нет и не может быть ожидаемого 
результата в виде «приложение вызывает ошибку в операционной си- 
‚ стеме и аварийно завершается с потерей всех пользовательских данных». _ 


“При этом корректная работа приложения вполне может предполагать 
отображение сообщений о неверных действиях пользователя или неких 
‚ критических ситуациях. Так, сообщение «Невозможно сохранить файл по 
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‚ — это не ошибка приложения, это его совершенно нормальная и правиль- | 
ная работа. Ошибкой приложения (в этой же ситуации) было бы отсут- 
ствие такого сообщения, и/или повреждение, или потеря записываемых | 





Для более глубокого понимания принципов оформления тест-кейсов реко- 
мендуется прямо сейчас ознакомиться с главой «Типичные ошибки при разработке 
чек-листов, тест-кейсов и наборов тест-кейсов» 7. 
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2.4.4. Инструментальные средства управления тестированием 


Инструментальных средств управления тестированием (test management 
1001295) очень много, к тому же многие компании разрабатывают свои внутренние 
средства решения этой задачи. 

Не имеет смысла заучивать, как работать с тест-кейсами в том или ином ин- 
струментальном средстве — принцип везде един, и соответствующие навыки нара- 
батываются буквально за пару дней. Что на текущий момент важно понимать, так 
это общий набор функций, реализуемых такими инструментальными средствами 
(конечно, то или иное средство может не реализовывать какую-то функцию из этого 
списка и/или реализовывать не вошедшие в список функции): 

e создание тест-кейсов и наборов тест-кейсов; 

e контроль версий документов с возможностью определить, кто внёс те или 
иные изменения, и отменить эти изменения, если требуется; 

• формирование и отслеживание реализации плана тестирования, сбор и ви- 
зуализация разнообразных метрик, генерирование отчётов; 

e интеграция с системами управления дефектами, фиксация взаимосвязи 
между выполнением тест-кейсов и созданными отчётами о дефектах; 

e интеграция с системами управления проектами; 

e интеграция с инструментами автоматизированного тестирования, управле- 
ние выполнением автоматизированных тест-кейсов. 


Иными словами, хорошее инструментальное средство управления тестиро- 
ванием берёт на себя все рутинные технические операции, которые объективно 
необходимо выполнять в процессе реализации жизненного цикла тестирования?”. 
Огромным преимуществом также является способность таких инструментальных 
средств отслеживать взаимосвязи между различными документами и иными арте- 
фактами, взаимосвязи между артефактами и процессами и т.д., подчиняя эти дей- 
ствия системе разграничения прав доступа и гарантируя сохранность и коррект- 
ность информации. 


Для общего развития и лучшего закрепления темы об оформлении тест-кей- 
сов?) мы сейчас рассмотрим несколько картинок с формами из разных инструмен- 
тальных средств. 

Здесь вполне сознательно не приведено никакого сравнения или подробного 
описания — подобных обзоров достаточно в Интернете, и они стремительно уста- 
ревают по мере выхода новых версий обозреваемых продуктов. 

Но интерес представляют отдельные особенности интерфейса, на которые 
мы обратим внимание в каждом из примеров (важно: если вас интересует подроб- 
ное описание каждого поля, связанных с ним процессов и т.д., обратитесь к офици- 
альной документации — здесь будут лишь самые краткие пояснения). 





296 Test management tool. А tool that provides support їо the test management апа control part of a test process. It often has several 
capabilities, such as testware management, scheduling of tests, the logging of results, progress tracking, incident management 
and test reporting. [ISTQB Glossary] 
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QAComplete?” 
oi (Auto Generate; (м -o 
Title: Status: 
Priority: =] Assigned To: 
Avg Run Time: (Auto Calculated) Last Run Status: (Auto Calculated) 
Last Run Test Set: (Auto Calculated) Last Run Configuration: 


Па 
Мы 


«у с 


Last Кип Release: 
Description: тад УХ жж = @ - 


Owner: у Мегѕіоп: 


Execution Туре: м Test Туре: 
Latest Notes: Add New Note 





Default Host Name: 


Linked Items: “ы Link to Items... 


File Attachments: Browse... 
Browse... 
Browse... 





Рисунок 2.4.c — Создание тест-кейса в QAComplete 


Іа (идентификатор), как видно из соответствующей надписи, автогенерируе- 
мый. 

Title (заглавие), как и в большинстве систем, является обязательным для за- 
полнения. 

Priority (приоритет) по умолчанию предлагает на выбор значения high (высо- 
кий), medium (средний), low (низкий). 

Folder пате (расположение) является аналогом полей «Модуль» и «Подмо- 
дуль» и позволяет выбрать из выпадающего древовидного списка соответ- 
ствующее значение, описывающее, к чему относится тест-кейс. 

Status (статус) показывает текущее состояние тест-кейса: пем (новый), ap- 
proved (утверждён), awaiting approval (на рассмотрении), іп design (в разра- 
ботке), outdated (устарел), rejected (отклонён). 

Аѕѕідпеа {о (исполнитель) указывает, кто в данный момент является «основ- 
ной рабочей силой» по данному тест-кейсу (или кто должен принять решение 
о, например, утверждении тест-кейса). 

Last Вип Status (результат последнего запуска) показывает, прошёл ли тест 
успешно (passed) или завершился неудачей (failed). 

Last Вип Configuration (конфигурация, использованная для последнего 3a- 
пуска) показывает, на какой аппаратно-программной платформе тест-кейс 





297 QAComplete [http://smartbear.com/product/test-management-tool/qacomplete/] 
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выполнялся в последний раз. 

9. Avg Вип Time (среднее время выполнения) содержит вычисленное автома- 
тически среднее время, необходимое на выполнение тест-кейса. 

10.Last Вип Test Set (в последний раз выполнялся в наборе) содержит инфор- 
мацию о наборе тест-кейсов, в рамках которого тест-кейс выполнялся по- 
следний раз. 

11.1аѕї Вип Release (последний раз выполнялся на выпуске) содержит инфор- 
мацию о выпуске (билде) программного средства, на котором тест-кейс вы- 
полнялся последний раз. 

12. Description (описание) позволяет добавить любую полезную информацию о 
тест-кейсе (включая особенности выполнения, приготовления и т.д.). 

13.Омпег (владелец) указывает на владельца тест-кейса (как правило — его aB- 
тора). 

14.Ехесийоп Туре (способ выполнения) по умолчанию предлагает только значе- 
ние manual (ручное выполнение), но при соответствующих настройках и NH- 
теграции с другими продуктами список можно расширить (как минимум доба- 
вить automated (автоматизированное выполнение)). 

15. Version (версия) содержит номер текущей версии тест-кейса (фактически — 
счётчик того, сколько раз тест-кейс редактировали). Вся история изменений 
сохраняется, предоставляя возможность вернуться к любой из предыдущих 
версий. 

16. Test Туре (вид теста) по умолчанию предлагает такие варианты, как negative 
(негативный), positive (позитивный), regression (регрессионный), smoke-test 
(дымовой). 

17. Default host пате (имя хоста по умолчанию) в основном используется в авто- 
матизированных тест-кейсах и предлагает выбрать из списка имя зареги- 
стрированного компьютера, на котором установлен специальный клиент. 

18. пкеа Пет (связанные объекты) представляют собой ссылки на требова- 
ния, отчёты о дефектах и т.д. 

19.Ейе Attachments (вложения) могут содержать тестовые данные, поясняющие 
изображения, видеоролики и т.д. 


Для описания шагов исполнения и ожидаемых результатов после сохране- 
НИЯ общего описания тест-кейса становится доступным дополнительный интер- 
фейс: 


Асйопз |] Step# Critical Steps Expected Results 
ох о 31 У 

ох 0 32 

ох о 3: 


Рисунок 2.4.4 — Добавление шагов тест-кейса в ОАСотрые 


При необходимости можно добавить и настроить свои дополнительные поля, 
значительно расширяющие исходные возможности системы. 
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Рисунок 2.4.е — Создание тест-кейса в TestLink 


Title (заглавие) здесь тоже является обязательным для заполнения. 
Ѕиттагу (описание) позволяет добавить любую полезную информацию о 
тест-кейсе (включая особенности выполнения, приготовления и т.д.). 

Steps (шаги выполнения) позволяет описать шаги выполнения. 

Expected Results (ожидаемые результаты) позволяет описать ожидаемые pe- 
зультаты, относящиеся к шагам выполнения. 

Available Keywords (доступные ключевые слова) содержит список ключевых 
слов, которые можно проассоциировать с тест-кейсом для упрощения клас- 
сификации и поиска тест-кейсов. Это ещё одна вариация идеи «Модулей» и 
«Подмодулей» (в некоторых системах реализованы оба механизма). 
Assigned Keywords (назначенные ключевые слова) содержит список ключе- 
вых слов, проассоциированных с тест-кейсом. 


Как видите, инструментальные средства управления тест-кейсами могут 


быть и достаточно минималистичными. 





298 TestLink [http://sourceforge.net/projects/testlink/] 





Тестирование программного обеспечения. Базовый курс. © ЕРАМ Systems, 2015-2021 Стр: 130/298 


Инструментальные средства управления тестированием 





TestRail29 


Add Test Case 


Title * 


27) 








Section 2) Туре * Priority * Estimate 
ж, ҖЕ, [x] 


Milestone References ? 


Preconditions 


The precon 


Steps 


























Я 


В © 


ditions of this test case. Reference other test cases with [< #] (e.g [< 17] 


Step Description Ө © 
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11 
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Expected Result 
Expected Result (10) 
2 Step Description о® 
13 в 
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Expected Result 
Expected Result 
Add Step 


Ҹ/ Add Test Case Ж Cancel 
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Рисунок 2.4.1 — Создание тест-кейса в TestRail 


Title (заглавие) здесь тоже является обязательным для заполнения. 

Section (секция) — очередная вариация на тему «Модуль» и «Подмодуль», 
позволяющая создавать иерархию секций, в которых можно размещать тест- 
кейсы. 

Туре (тип) здесь по умолчанию предлагает выбрать один из вариантов: auto- 
mated (автоматизированный), functionality (проверка функциональности), per- 
formance (производительность), regression (регрессионный), usability (удоб- 
ство использования), оїһег (прочее). 

Priority (приоритет) здесь представлен числами, по которым распределены 
следующие словесные описания: must test (обязательно выполнять), test ії 





299 Тез{Вай [http://www.gurock.com/testrail/] 
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time (выполнять, если будет время), don’t test (не выполнять). 

5. Estimate (оценка) содержит оценку времени, которое необходимо затратить 
на выполнение тест-кейса. 

6. Milestone (ключевая точка) позволяет указать ключевую точку проекта, к KO- 
торой данный тест-кейс должен устойчиво показывать положительный ре- 
зультат (выполняться успешно). 

7. References (ссылки) позволяет хранить ссылки на такие артефакты, как тре- 
бования, пользовательские истории, отчёты о дефектах и иные документы 
(требует дополнительной настройки). 

8. Preconditions (приготовления) представляет собой классику описания пред- 
варительных условий и необходимых приготовлений к выполнению тест- 
кейса. 

9. Step Description (описание шага) позволяет добавлять описание отдельного 
шага тест-кейса. 

10. Expected Results (ожидаемые результаты) позволяет описать ожидаемый pe- 
зультат по каждому шагу. 





Задание 2.4.с: изучите ещё 3—5 инструментальных средств управления 
‚ Тест-кейсами, почитайте документацию по ним, посоздавайте в них He- 7 
олько тест-кейсов. 
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2.4.5. Свойства качественных тест-кейсов 


Даже правильно оформленный тест-кейс может оказаться некачественным, 


если в нём нарушено одно из следующих свойств. 


Правильный технический язык, точность и единообразие формулиро- 


вок. Это свойство в равной мере относится и к требованиям, и к тест-кейсам, и к 
отчётам о дефектах — к любой документации. Основные идеи уже были описаны 
(см. главу «Атрибуты (поля) тест-кейсов»!2'), а из самого общего и важного напом- 
ним и добавим: 


пишите лаконично, но понятно; 

используйте безличную форму глаголов (например, «открыть» вместо «от- 
кройте»); 

обязательно указывайте точные имена и технически верные названия эле- 
ментов приложения; 

не объясняйте базовые принципы работы с компьютером (предполагается, 
что ваши коллеги знают, что такое, например, «пункт меню» и как с ним ра- 
ботать); 

везде называйте одни и те же вещи одинаково (например, нельзя в одном 
тест-кейсе некий режим работы приложения назвать «графическое представ- 
ление», а в другом тот же режим — «визуальное отображение», т.к. многие 
люди могут подумать, что речь идёт о разных вещах); 

следуйте принятому на проекте стандарту оформления и написания тест- 
кейсов (иногда такие стандарты могут быть весьма жёсткими: вплоть до ре- 
гламентации того, названия каких элементов должны быть приведены в 
двойных кавычках, а каких — в одинарных). 


Баланс между специфичностью и общностью. Тест-кейс считается тем 


более специфичным, чем более детально в нём расписаны конкретные действия, 
конкретные значения и т.д., т.е. чем в нём больше конкретики. Соответственно, 
тест-кейс считается тем более общим, чем в нём меньше конкретики. 


Рассмотрим поля «шаги» и «ожидаемые результаты» двух тест-кейсов (по- 


думайте, какой тест-кейс вы бы посчитали хорошим, а какой — плохим и почему): 


Тест-кейс 1: 





Шаги Ожидаемые результаты 





Конвертация из всех поддерживаемых коди- | 1. 


Отображается консольный журнал приложе- 





ровок 
Приготовления: 


Создать папки С:/А, С:/В, СУС, СУР. 
Разместить в папке С:/0 файлы 1.html, 2.46% 
З.та из прилагаемого архива. 

Запустить приложение, выполнив команду 
«php сопмейег.рһр с:/а с/р с:/с/соп- 
verter.log». 

Скопировать файлы 1.html, 2.txt, З.та из 
папки C:/D в папку С:/А. 

Остановить приложение нажатием Ctrl+C. 





ния с сообщением «текущее время started, 
source dir с:/а, destination dir c:/b, log Ме 
c:/c/converter.log», в папке С:/С появляется 
файл converter.log, в котором появляется за- 
пись «текущее_время started, source dir с:/а, 
destination dir c:/b, log file с:/с/сопуецег.!од». 

Файлы 1.html, 2.txt, 3.md появляются в папке 
С:/А, затем пропадают оттуда и появляются 
в папке С:/В. В консольном журнале и файле 
C:/C/converter.log появляются сообщения 
(записи) «текущее время processing 1.html 
(KOI8-R)», «текущее_время processing 2.txt 
(CP-1251)», «текущее время processing 
3.md (CP-866)». 

В файле C:/C/converter.log появляется 3a- 
пись «текущее время closed». Приложение 
завершает работу. 
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Тест-кейс 2: 





Шаги 


Ожидаемые результаты 





Конвертация из всех поддерживаемых коди- 

ровок 

1. Выполнить конвертацию трёх файлов допу- 
стимого размера в трёх разных кодировках 
всех трёх допустимых форматов. 








1. 


Файлы перемещаются в папку-приёмник, ко- 
дировка всех файлов меняется на ЦТЕ-8. 








Если вернуться к вопросу «какой тест-кейс вы бы посчитали хорошим, а какой 


— плохим и почему», то ответ таков: оба тест-кейса плохие потому, что первый 
является слишком специфичным, а второй — слишком общим. Можно сказать, что 
здесь до абсурда доведены идеи низкоуровневых!! и высокоуровневых!” TECT- 
кейсов. 


Почему плоха излишняя специфичность (тест-кейс 1): 

при повторных выполнениях тест-кейса всегда будут выполняться строго 
одни и те же действия со строго одними и теми же данными, что снижает 
вероятность обнаружения ошибки; 

возрастает время написания, доработки и даже просто прочтения тест-кейса; 
в случае выполнения тривиальных действий опытные специалисты тратят 
дополнительные мыслительные ресурсы в попытках понять, что же они упу- 
стили из виду, т.к. они привыкли, что так описываются только самые сложные 
и неочевидные ситуации. 


Почему плоха излишняя общность (тест-кейс 2): 

тест-кейс сложен для выполнения начинающими тестировщиками или даже 
опытными специалистами, лишь недавно подключившимися к проекту; 
недобросовестные сотрудники склонны халатно относиться к таким тест-кей- 
сам; 

тестировщик, выполняющий тест-кейс, может понять его иначе, чем было за- 
думано автором (и в итоге будет выполнен фактически совсем другой тест- 
кейс). 


Выход из этой ситуации состоит в том, чтобы придерживаться золотой сере- 


ДИНЫ (хотя, конечно же, какие-то тесты будут чуть более специфичными, какие-то 


— чуть более общими). Вот пример такого срединного подхода: 


Тест-кейс 3: 





Шаги 


Ожидаемые результаты 





Конвертация из всех поддерживаемых коди- 
ровок 
Приготовления: 


стовых файлов. 

1. Запустить приложение, указав в параметрах 
соответствующие пути из приготовления к 
тесту (имя файла журнала — произволь- 
ное). 

2. Скопировать файлы из папки для времен- 
ного хранения в папку для входных файлов. 

3. Остановить приложение. 








=ï 


e Создать в корне любого диска четыре от- | 2. Файлы из папки для входных файлов nepe- 
дельные папки для входных файлов, выход- мещаются в папку для выходных файлов, в 
ных файлов, файла журнала и временного консоли и файле журнала отображаются со- 
хранения тестовых файлов. общения о конвертации каждого из файлов 

• Распаковать содержимое прилагаемого ар- с указанием его исходной кодировки. 
хива в папку для временного хранения те- | 3. Приложение выводит сообщение о завер- 


Приложение запускается и выводит сообще- 
ние о своём запуске в консоль и файл жур- 
нала. 


шении работы в файл журнала и завершает 
работу. 
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В этом тест-кейсе есть всё необходимое для понимания и выполнения, но 
при этом он стал короче и проще для выполнения, а отсутствие строго указанных 
значений приводит к тому, что при многократном выполнении тест-кейса (особенно 
— разными тестировщиками) конкретные параметры будут менять свои значения, 
что увеличивает вероятность обнаружения ошибки. 

Ещё раз главная мысль: сами по себе специфичность или общность тест- 
кейса не являются чем-то плохим, но резкий перекос в ту или иную сторону снижает 
качество тест-кейса. 


Баланс между простотой и сложностью. Здесь не существует академиче- 
ских определений, но принято считать, что простой тест-кейс оперирует одним объ- 
ектом (или в нём явно виден главный объект), а также содержит небольшое коли- 
чество тривиальных действий; сложный тест-кейс оперирует несколькими равно- 
правными объектами и содержит много нетривиальных действий. 


Преимущества простых тест-кейсов: 

e их можно быстро прочесть, легко понять и выполнить; 

e они понятны начинающим тестировщикам и новым людям на проекте; 

» они делают наличие ошибки очевидным (как правило, в них предполагается 
выполнение повседневных тривиальных действий, проблемы с которыми 
видны невооружённым взглядом и не вызывают дискуссий); 

e они упрощают начальную диагностику ошибки, т.к. сужают круг поиска. 


Преимущества сложных тест-кейсов: 

• при взаимодействии многих объектов повышается вероятность возникнове- 
ния ошибки; 

• пользователи, как правило, используют сложные сценарии, а потому слож- 
ные тесты более полноценно эмулируют работу пользователей; 

e программисты редко проверяют такие сложные случаи (и они совершенно не 
обязаны это делать). 


Рассмотрим примеры. 


Слишком простой тест-кейс: 

















Шаги Ожидаемые результаты 
Запуск приложения 1. Приложение запускается. 
1. Запустить приложение. 





Слишком сложный тест-кейс: 





Шаги 
Повторная конвертация 2. 
Приготовлен ия: 


Ожидаемые результаты 
Файлы постепенно перемещаются из вход- 
ной в выходную папку, в консоли и файле 








e Создать в корне любого диска три отдель- 


ные папки для входных файлов, выходных 
файлов, файла журнала. 

Подготовить набор из нескольких файлов 
максимального поддерживаемого размера 
поддерживаемых форматов с поддерживае- 
мыми кодировками, а также нескольких фай- 
лов допустимого размера, но недопустимого 
формата. 

Запустить приложение, указав в параметрах 
соответствующие пути из приготовления к 
тесту (имя файла журнала — произволь- 
ное). 





журнала появляются сообщения об успеш- 
ной конвертации файлов. 
Файлы постепенно перемещаются из вход- 
ной в выходную папку, в консоли и файле 
журнала появляются сообщения об успеш- 
ной конвертации файлов. 


Файлы постепенно перемещаются из вход- 
ной в выходную папку, в консоли и файле 
журнала появляются сообщения об успеш- 
ной конвертации файлов допустимого фор- 
мата и сообщения об игнорировании фай- 
лов недопустимого формата. 
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Файлы постепенно перемещаются из вход- 
ной в выходную папку, в консоли и файле 
журнала появляются сообщения об успеш- 
ной конвертации файлов допустимого фор- 
мата и сообщения об игнорировании фай- 
лов недопустимого формата. 


2. Скопировать в папку для входных файлов | 6. 
несколько файлов допустимого формата. 

3. Переместить сконвертированные файлы из 
папки с результирующими файлами в папку 
для входных файлов. 

4. Переместить сконвертированные файлы из 
папки с результирующими файлами в папку 
с набором файлов для теста. 

5. Переместить все файлы из папки с набором 
файлов для теста в папку для входных фай- 
лов. 

6. Переместить сконвертированные файлы из 
папки с результирующими файлами в папку 
для входных файлов. 














Этот тест-кейс одновременно является слишком сложным по избыточности 
действий и по спецификации лишних данных и операций. 


‚ Задание 2.4.4: перепишите этот тест-кейс, устранив его недостатки, но 
сохранив общую цель (проверку повторной конвертации уже ранее скон- 





Примером хорошего простого тест-кейса может служить тест-кейс 3034 из 
пункта про специфичность и общность. 
Пример хорошего сложного тест-кейса может выглядеть так: 





Шаги 
Много копий приложения, конфликт фай- | 3. 
ловых операций 
Приготовления: 
• Создать в корне любого диска три от- 
дельные папки для входных файлов, вы- 


Ожидаемые результаты 
Все три копии приложения запускаются, в 
файле журнала появляются последовательно 
три записи о запуске приложения. 





5. Файлы постепенно перемещаются из входной в 





ходных файлов, файла журнала. 
Подготовить набор из нескольких фай- 
лов максимального поддерживаемого 
размера поддерживаемых форматов с 
поддерживаемыми кодировками. 
Запустить первую копию приложения, 
указав в параметрах соответствующие 
пути из приготовления к тесту (имя 
файла журнала — произвольное). 


ходных файлов в папку для входных фай- 
лов. 





выходную папку, в консоли и файле журнала 
появляются сообщения об успешной конверта- 
ции файлов, а также (возможно) сообщения 
вида: 

а. “source file inaccessible, retrying”. 

b. “destination file inaccessible, retrying”. 

c. “log file inaccessible, retrying”. 


Ключевым показателем корректной работы AB- 
ляется успешная конвертация всех файлов, а 


2. Запустить вторую копию приложения с также появление в консоли и файле журнала 
теми же параметрами (см. шаг 1). сообщений об успешной конвертации каждого 
3. Запустить третью копию приложения с файла (от одной до трёх записей на каждый 
теми же параметрами (см. шаг 1). файл). 
4. Изменить приоритет процессов второй 
(“high”) и третьей (“low”) копий. Сообщения (предупреждения) о недоступности 
5. Скопировать подготовленный набор ис- входного файла, выходного файла или файла 


журнала также являются показателем коррект- 
ной работы приложения, однако их количество 
зависит от многих внешних факторов и не мо- 
жет быть спрогнозировано заранее. 








Иногда более сложные тест-кейсы являются также и более специфичными, 
но это лишь общая тенденция, а не закон. Также нельзя по сложности тест-кейса 
однозначно судить о его приоритете (в нашем примере хорошего сложного тест- 
кейса он явно будет иметь очень низкий приоритет, т.к. проверяемая им ситуация 
является искусственной и крайне маловероятной, но бывают и сложные тесты с 
самым высоким приоритетом). 
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Как и в случае специфичности и общности, сами по себе простота или слож- 
ность тест-кейсов не являются чем-то плохим (более того — рекомендуется начи- 
нать разработку и выполнение тест-кейсов с простых, а затем переходить ко всё 
более и более сложным), однако излишняя простота и излишняя сложность также 
снижают качество тест-кейса. 


«Показательность» (высокая вероятность обнаружения ошибки). Начи- 
ная с уровня тестирования критического пути, можно утверждать, что тест-кейс 
является тем более хорошим, чем он более показателен (с большей вероятностью 
обнаруживает ошибку). Именно поэтому мы считаем непригодными слишком про- 
стые тест-кейсы — они непоказательны. 


Пример непоказательного (плохого) тест-кейса: 








Шаги Ожидаемые результаты 
Запуск и остановка приложения 1. Приложение запускается. 
1. Запустить приложение с корректными пара- | 2. Приложение завершает работу. 


метрами. 
2. Завершить работу приложения. 





Пример показательного (хорошего) тест-кейса: 








Шаги Ожидаемые результаты 

Запуск с некорректными параметрами, несу- | 1. В консоли отображаются нижеуказанные со- 
ществующие пути общения, приложение завершает работу. 
1. Запустить приложение со всеми тремя пара- Сообщения: 

метрами (SOURCE_DIR, DESTINA- а. Сообщение об использовании. 

ТОМ ВІА, 10Ә ЕЕ МАМЕ), значения Ko- р. SOURCE_DIR [z\src\]: directory пої exists 

торых указывают на несуществующие в ог inaccessible. 

файловой системе пути (например: 2\5гс\, с. ОЕЅТІМАТІОМ РІА [2\4$\]: directory пої 

2\4$\, 209.04 при условии, что в системе exists ог inaccessible. 

нет логического диска Z). а. Оа ЕЕ МАМЕ [z\\log.txt]: wrong file 











пате ог inaccessible path. 





Обратите внимание, что показательный тест-кейс по-прежнему остался до- 
статочно простым, но он проверяет ситуацию, возникновение ошибки в которой 
несравненно более вероятно, чем в ситуации, описываемой плохим непоказатель- 
ным тест-кейсом. 

Также можно сказать, что показательные тест-кейсы часто выполняют какие- 
то «интересные действия», т.е. такие действия, которые едва ли будут выполнены 
просто в процессе работы с приложением (например: «сохранить файл» — это 
обычное тривиальное действие, которое явно будет выполнено не одну сотню раз 
даже самими разработчиками, а вот «сохранить файл на носитель, защищённый от 
записи», «сохранить файл на носитель с недостаточным объёмом свободного про- 
странства», «сохранить файл в папку, к которой нет доступа» — это уже гораздо 
более интересные и нетривиальные действия). 
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Последовательность в достижении цели. Суть этого свойства выражается 
в том, что все действия в тест-кейсе направлены на следование единой логике и 
достижение единой цели и не содержат никаких отклонений. 

Примерами правильной реализации этого свойства могут служить представ- 
ленные в этом разделе в избытке примеры хороших тест-кейсов. А нарушение мо- 


жет выглядеть так: 





Шаги 


Ожидаемые результаты 





Конвертация из всех поддерживаемых коди- 

ровок 

Приготовления: 

• Создать в корне любого диска четыре от- 
дельные папки для входных файлов, выход- 
ных файлов, файла журнала и временного 
хранения тестовых файлов. 

• Распаковать содержимое прилагаемого ар- 
хива в папку для временного хранения те- 
стовых файлов. 

1. Запустить приложение, указав в параметрах 
соответствующие пути из приготовления к 
тесту (имя файла журнала — произволь- 
ное). 

2. Скопировать файлы из папки для времен- 

ного хранения в папку для входных файлов. 

Остановить приложение. 

Удалить файл журнала. 

Повторно запустить приложение с теми же 

параметрами. 

6. Остановить приложение. 


me gw 








= 


Приложение запускается и выводит сообще- 
ние о своём запуске в консоль и файл жур- 
нала. 

2. Файлы из папки для входных файлов пере- 
мещаются в папку для выходных файлов, в 
консоли и файле журнала отображаются со- 
общения о конвертации каждого из файлов 
с указанием его исходной кодировки. 

3. Приложение выводит сообщение о завер- 

шении работы в файл журнала и завершает 

работу. 


5. Приложение запускается и выводит сообще- 
ние о своём запуске в консоль и заново со- 
зданный файл журнала. 

6. Приложение выводит сообщение о завер- 
шении работы в файл журнала и завершает 
работу. 








Шаги 3—5 никак не соответствуют цели тест-кейса, состоящей в проверке кор- 
ректности конвертации входных данных, представленных во всех поддерживаемых 
кодировках. 


Отсутствие лишних действий. Чаще всего это свойство подразумевает, что 
не нужно в шагах тест-кейса долго и по пунктам расписывать то, что можно заме- 


нить одной фразой: 








2. Указать в качестве второго параметра при- 
ложения путь к папке с конечными файлами. 
3. Указать в качестве третьего параметра при- 


Плохо Хорошо 
1. Указать в качестве первого параметра при- | 1. Запустить приложение со всеми тремя кор- 
ложения путь к папке с исходными файлами. | ректными параметрами (например, с\$гс\, 


ci\dst\, с\од.іхі при условии, что соответствую- 
щие папки существуют и доступны приложе- 
нию). 


ложения путь к файлу журнала. 
4. Запустить приложение. 














Вторая по частоте ошибка — начало каждого тест-кейса с запуска приложе- 
ния и подробного описания по приведению его в то или иное состояние. В наших 
примерах мы рассматриваем каждый тест-кейс как существующий в единственном 
виде в изолированной среде, и потому вынуждены осознанно допускать эту ошибку 
(иначе тест-кейс будет неполным), но в реальной жизни на запуск приложения бу- 
дут свои тесты, а длинный путь из многих действий можно описать как одно дей- 
ствие, из контекста которого понятно, как это действие выполнить. 
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Следующий пример тест-кейса не относится к нашему «Конвертеру файлов», 
но очень хорошо иллюстрирует эту мысль: 








Плохо Хорошо 
1. Запустить приложение. 1. Открыть ВОСХ-файл с тремя и более страни- 
2. Выбрать в меню пункт «Файл». цами. 


3. Выбрать подпункт «Открыть». 

4. Перейти в папку, в которой находится хотя бы 
один файл формата DOCX с тремя и более 
страницами. 














И сюда же можно отнести ошибку с повторением одних и тех же приготовле- 
ний во множестве тест-кейсов (да, по описанным выше причинам в примерах мы 
снова вынужденно делаем так, как в жизни делать не надо). Куда удобнее объеди- 
нить тесты в набор!“ и указать приготовления один раз, подчеркнув, нужно или нет 
их выполнять перед каждым тест-кейсом в наборе. 


т] Проблема с подготовительными (и финальными) действиями идеально 
| ‚ решена в автоматизированном модульном тестированиизо с использова- 
нием фреймворков наподобие JUnit или TestNG — там существует специ- | 
‚ альный «механизм фиксаций» (fixture), автоматически выполняющий ука- | 
‚ занные действия перед каждым отдельным тестовым методом (или их CO- 





Неизбыточность по отношению к другим тест-кейсам. В процессе созда- 
ния множества тест-кейсов очень легко оказаться в ситуации, когда два и более 
тест-кейса фактически выполняют одни и те же проверки, преследуют одни и те же 
цели, направлены на поиск одних и тех же проблем. Способ минимизации количе- 
ства таких тест-кейсов подробно описан в главе «Виды и направления тестирова- 
ния%4» (см. такие техники тестирования, как использование классов эквивалентно- 
сти? и граничных условий?) 

Если вы обнаруживаете несколько тест-кейсов, дублирующих задачи друг 
друга, лучше всего или удалить все, кроме одного, самого показательного, или пе- 
ред удалением остальных на их основе доработать этот выбранный самый показа- 
тельный тест-кейс. 


Демонстративность (способность демонстрировать обнаруженную 
ошибку очевидным образом). Ожидаемые результаты должны быть подобраны 
и сформулированы таким образом, чтобы любое отклонение от них сразу же бро- 
салось в глаза и становилось очевидным, что произошла ошибка. Сравните вы- 
держки из двух тест-кейсов. 


Выдержка из недемонстративного тест-кейса: 





Шаги Ожидаемые результаты 

5. Разместить в файле текст «Пример длин- | 6. Приложение игнорирует файл. 
ного текста, содержащего символы русского | 7. Текст принимает корректный вид в коди- 
и английского алфавита вперемешку.» в ко- ровке UTF-8 с учётом английских букв. 
дировке KOI8-R (в слове «Пример» буквы 
«р» — английские). 

6. Сохранить файл под именем «test. txt» и OT- 
править файл на конвертацию. 

7. Переименовать файл в «test.txt». 




















300 Unit testing (component testing). The testing of individual software components. [ISTQB Glossary] 
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Выдержка из демонстративного тест-кейса: 








Шаги Ожидаемые результаты 
5. Разместить в файле текст «Ёт-=т | 6. Текст принимает вид: «Пример текста.» 
Ыт h.» (Эти символы представляют co- (кодировка UTF8). 


бой словосочетание «Пример текста.» в коди- 
ровке КО!8-В, прочитанной как СР866). 
6. Отправить файл на конвертацию. 














В первом случае тест-кейс плох не только расплывчатостью формулировки 
«корректный вид в кодировке ОТЕ-8 с учётом английских букв», там также очень 
легко допустить ошибки при выполнении: 

e забыть сконвертировать вручную входной текст в КО!8-В; 

e не заметить, что в первый раз расширение начинается с пробела; 

e забыть заменить в слове «Пример» буквы «р» на английские; 

e из-за расплывчатости формулировки ожидаемого результата принять OWM- 
бочное, но выглядящее правдоподобно поведение за верное. 


Второй тест-кейс чётко ориентирован на свою цель по проверке конвертации 
(не содержит странной проверки с игнорированием файла с неверным расшире- 
нием) и описан так, что его выполнение не представляет никаких сложностей, а лю- 
бое отклонение фактического результата от ожидаемого будет сразу же заметно. 


Прослеживаемость. Из содержащейся в качественном тест-кейсе информа- 
ции должно быть понятно, какую часть приложения, какие функции и какие требо- 
вания он проверяет. Частично это свойство достигается через заполнение соответ- 
ствующих полей тест-кейса!'2" («Ссылка на требование», «Модуль», «Подмодуль»), 
но и сама логика тест-кейса играет не последнюю роль, т.к. в случае серьёзных 
нарушений этого свойства можно долго с удивлением смотреть, например, на какое 
требование ссылается тест-кейс, и пытаться понять, как же они друг с другом свя- 
заны. 


Пример непрослеживаемого тест-кейса: 








Тре- | Модуль | Подмо- Шаги Ожидаемые результаты 
бо- дуль 
ва- 
ние 
ПТ-4 | Прило- Совмещение кодировок 1. Допустимые кодировки конвер- 
жение Приготовления: файл с не- тируются верно, недопустимые 
сколькими допустимыми и остаются без изменений. 
недопустимыми кодиров- 
ками. 
1. Передать файл на конвер- 
тацию. 























Да, этот тест-кейс плох сам по себе (в качественном тест-кейсе сложно полу- 
чить ситуацию непрослеживаемости), но в нём есть и особые недостатки, затруд- 
няющие прослеживаемость: 

e Ссылка на несуществующее требование (убедитесь сами, требования ПТ-4 
нет5”7). 

e В поле «Модуль» указано значение «Приложение» (по большому счёту 
можно было оставлять это поле пустым — это было бы столь же информа- 
тивно), поле «Подмодуль» не заполнено. 

• По заглавию и шагам можно предположить, что этот тест-кейс ближе всего к 
ДС-5.1 и ДС-5.3, но сформулированный ожидаемый результат не следует 
явно из этих требований. 
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Пример прослеживаемого тест-кейса: 








Требование Модуль Подмодуль Шаги Ожидаемые результаты 

ДС-2.4, Стартер Обработчик | Запуск с некоррект- 1. В консоли отображаются 

ДС-3.2 ошибок ными параметрами, нижеуказанные сообще- 
несуществующие ния, приложение завер- 
пути шает работу. Сообщения 


1. Запустить приложе- а. SOURCE ІА [путь]: 


ние со всеми тремя 
параметрами, зна- 
чения которых ука- 


directory пої exists ог 
inaccessible. 


. DESTINATION_DIR 


зывают на несуще- [путь]: directory пої 
ствующие в файло- exists ог inaccessible. 
вой системе пути. с. ГОС ЕЕ МАМЕ 
[имя]: wrong file пате 
ог inaccessible path. 























Можно подумать, что этот тест-кейс затрагивает ДС-2 и ДС-3 целиком, HO B 
поле «Требование» есть вполне чёткая конкретизация, к тому же указанные мо- 
дуль, подмодуль и сама логика тест-кейса устраняют оставшиеся сомнения. 

Некоторые авторы также подчёркивают, что прослеживаемость тест-кейса 
связана с его неизбыточностью! по отношению к другим тест-кейсам (намного 
проще дать ссылку на один уникальный тест-кейс, чем выбирать из нескольких 
очень похожих). 


Возможность повторного использования. Это свойство редко выполня- 
ется для низкоуровневых тест-кейсов''®, но при создании высокоуровневых TECT- 
кейсов!” можно добиться таких формулировок, при которых: 

e тест-кейс будет пригодным к использованию с различными настройками TE- 
стируемого приложения и в различных тестовых окружениях; 

• тест-кейс практически без изменений можно будет использовать для тести- 
рования аналогичной функциональности в других проектах или других обла- 
стях приложения. 


Примером тест-кейса, который тяжело использовать повторно, может яв- 
ляться практически любой тест-кейс с высокой специфичностью. 

Не самым идеальным, но очень наглядным примером тест-кейса, который 
может быть легко использован в разных проектах, может служить следующий тест- 
кейс: 





Шаги 

Запуск, все параметры некорректны 1. 

1. Запустить приложение, указав в качестве 

всех параметров заведомо некорректные 
значения. 


Ожидаемые результаты 
Приложение запускается, после чего выво- 
дит сообщение с описанием сути проблемы 
с каждым из параметров и завершает ра- 
боту. 

















Повторяемость. Тест-кейс должен быть сформулирован таким образом, 
чтобы при многократном повторении он показывал одинаковые результаты. Это 
свойство можно разделить на два подпункта: 

èe во-первых, даже общие формулировки, допускающие разные варианты Bbl- 
полнения тест-кейса, должны очерчивать соответствующие явные границы 

(например: «ввести какое-нибудь число» — плохо, «ввести целое число в 

диапазоне от -273 до +500 включительно» — хорошо); 

e действия (шаги) тест-кейса по возможности не должны приводить к необра- 
тимым (или сложно обратимым) последствиям (например: удалению данных, 
нарушению конфигурации окружения и т.д.) — не стоит включать в тест-кейс 
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такие «разрушительные действия», если они не продиктованы явным обра- 
зом целью тест-кейса; если же цель тест-кейса обязывает нас к выполнению 
таких действий, в самом тест-кейсе должно быть описание действий по вос- 
становлению исходного состояния приложения (данных, окружения). 


Соответствие принятым шаблонам оформления и традициям. С шабло- 
нами оформления, как правило, проблем не возникает: они строго определены име- 
ющимся образцом или вообще экранной формой инструментального средства 
управления тест-кейсами. Что же касается традиций, то они отличаются даже в раз- 
ных командах в рамках одной компании, и тут невозможно дать иного совета, кроме 
как «почитайте уже готовые тест-кейсы перед тем как писать свои». 

В данном случае обойдёмся без отдельных примеров, т.к. выше и без того 
приведено много правильно оформленных тест-кейсов, а что касается нарушений 
этого свойства, то они прямо или косвенно описаны в главе «Типичные ошибки при 
разработке чек-листов, тест-кейсов и наборов тест-кейсов» "57. 
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2.4.6. Наборы тест-кейсов 


Терминология и общие сведения 





‚ Набор тест-кейсов (test case ѕийезо, test suite, test set) — совокупность | 
‚ тест-кейсов, выбранных с некоторой общей целью или по некоторому об- | 
‚ щему признаку. Иногда в такой совокупности результаты завершения OA- 
‚ ного тест-кейса становятся входным состоянием приложения для следую- | 





‘` кейсов» говорят «тестовый сценарий». Формально это можно считать | 
‚ ошибкой, но это явление приобрело настолько широкое распространение, | 
что стало вариантом нормы. | 


_ Внимание! Из-за особенностей перевода очень часто вместо «набор тест- ' 








Как мы только что убедились на примере множества отдельных тест-кейсов, 
крайне неудобно (более того, это ошибка!) каждый раз писать в каждом тест-кейсе 
одни и те же приготовления и повторять одни и те же начальные шаги. 

Намного удобнее объединить несколько тест-кейсов в набор или последова- 
тельность. И здесь мы приходим к классификации наборов тест-кейсов. 


В общем случае наборы тест-кейсов можно разделить на свободные (поря- 
док выполнения тест-кейсов не важен) и последовательные (порядок выполнения 
тест-кейсов важен). 


Преимущества свободных наборов: 

e Тест-кейсы можно выполнять в любом удобном порядке, а также создавать 
«наборы внутри наборов». 

• Если какой-то тест-кейс завершился ошибкой, это не повлияет на возмож- 
ность выполнения других тест-кейсов. 


Преимущества последовательных наборов: 

• Каждый следующий в наборе тест-кейс в качестве входного состояния при- 
ложения получает результат работы предыдущего тест-кейса, что позволяет 
сильно сократить количество шагов в отдельных тест-кейсах. 

e Длинные последовательности действий куда лучше имитируют работу pe- 
альных пользователей, чем отдельные «точечные» воздействия на приложе- 
ние. 


Пользовательские сценарии (сценарии использования) 






В данном случае речь НЕ идёт о use cases (вариантах использования), 
представляющих собой форму требований. Пользовательские сцена- 
рии как техника тестирования куда менее формализованы, хотя и могут | 





К отдельному подвиду последовательных наборов тест-кейсов (или даже 
неоформленных идей тест-кейсов, таких, как пункты чек-листа) можно отнести 
пользовательские сценариизо (или сценарии использования), представляющие CO- 
бой цепочки действий, выполняемых пользователем в определённой ситуации для 
достижения определённой цели. 





301 Test case suite (test suite, test set). А set ої several test cases for а component ог system under test, where the post condition 
of one test is often used as the precondition for the next one. [ISTQB Glossary] 

302 A scenario is a hypothetical story, used to help a person think through a complex problem or system. [Cem Kaner, «An Introduction 
to Scenario Testing», http://www.kaner.com/pdfs/ScenariolntroVer4.pdf] 
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Поясним это сначала на примере, не относящемся к «Конвертеру файлов». 


Допустим, пользователь хочет распечатать табличку на дверь кабинета с текстом 
«Идёт работа, не стучать!» Для этого ему нужно: 


Запустить текстовый редактор. 

Создать новый документ (если редактор не делает это самостоятельно). 
Набрать в документе текст. 

Отформатировать текст должным образом. 

Отправить документ на печать. 

Сохранить документ (спорно, но допустим). 

Закрыть текстовый редактор. 


Вот мы и получили пользовательский сценарий, пункты которого могут стать 


основой для шагов тест-кейса или целого набора отдельных тест-кейсов. 


Сценарии могут быть достаточно длинными и сложными, могут содержать 


внутри себя циклы и условные ветвления, но при всём этом они обладают рядом 
весьма интересных преимуществ: 


Сценарии показывают реальные и понятные примеры использования про- 
дукта (в отличие от обширных чек-листов, где смысл отдельных пунктов мо- 
жет теряться). 

Сценарии понятны конечным пользователям и хорошо подходят для обсуж- 
дения и совместного улучшения. 

Сценарии и их части легче оценивать с точки зрения важности, чем отдель- 
ные пункты (особенно низкоуровневых) требований. 

Сценарии отлично показывают недоработки в требованиях (если становится 
непонятно, что делать в том или ином пункте сценария, — с требованиями 
явно что-то не то). 

В предельном случае (нехватка времени и прочие форс-мажоры) сценарии 
можно даже не прописывать подробно, а просто именовать — и само наиме- 
нование уже подскажет опытному специалисту, что делать. 


Последний пункт проиллюстрируем на примере. Классифицируем потенци- 


альных пользователей нашего приложения (напомним, что в нашем случае «поль- 
зователь» — это администратор, настраивающий работу приложения) по степени 
квалификации и склонности к экспериментам, а затем дадим каждому «виду поль- 
зователя» запоминающееся имя. 


Таблица 2.4.а — Классификация пользователей 























Низкая квалификация Высокая квалификация 
Не склонен к экспериментам | «Осторожный» «Консервативный» 
Склонен к экспериментам «Отчаянный» «Изощрённый» 





Согласитесь, уже на этой стадии не составляет труда представить себе от- 


личия в логике работы с приложением, например, «консервативного» и «отчаян- 
ного» пользователей. 


Но мы пойдём дальше и озаглавим для них сами сценарии, например, в си- 


туациях, когда такой пользователь позитивно и негативно относится к идее внедре- 
ния нашего приложения: 
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Таблица 2.4.6 — Сценарии поведения на основе классификации пользователей 





«Осторожный» 


«Консерватив- 
ный» 


«Отчаянный» 


«Изощрённый» 





«А можно вот 


«Начнём с ин- 


«Гляньте, что я 


«Я всё оптимизи- 























Позитивно 
так?» струкции!» придумал!» рую!» 
«Я ничего не по- | «У вас вот здесь | «Всё равно поло- | «А я говорил!» 
Негативно нимаю.» несоответ- маю!» 
ствие...» 





Проявив даже самую малость воображения, можно представить, что и как 
будет происходить в каждой из получившихся восьми ситуаций. Причём на созда- 
ние пары таких таблиц уходит всего несколько минут, а эффект от их использова- 
ния на порядки превосходит бездумное «кликанье по кнопкам в надежде найти баг». 


‚ Куда более полное и техничное объяснение того, что такое сценарное Te- 
‚ стирование, как его применять и выполнять должным образом, можно про- . 





Представленный здесь материал сложно отнести к категории «для начи- | 
‚ нающих» (и вы можете сразу перейти к пункту «Принципы построения 
‚ наборов тест-кейсов»!“”). Но если вам любопытно, взгляните на подроб- . 





Подробная классификация наборов тест-кейсов может быть выражена сле- 
дующей таблицей. 


Таблица 2.4.с — Подробная классификация наборов тест-кейсов 





По изолированности тест-кейсов друг от 
друга 





Изолированные 


Обобщённые 





По образованию тест- 
кейсами строгой по- 
следовательности 


Свободные 


Изолированные 
свободные 


Обобщённые свобод- 
ные 





Последовательные 


Изолированные 
последовательные 


Обобщённые 
последовательные 

















e Набор изолированных свободных тест-кейсов (рисунок 2.4.0): действия из 
раздела «приготовления» нужно повторить перед каждым тест-кейсом, а 
сами тест-кейсы можно выполнять в любом порядке. 

e Набор обобщённых свободных тест-кейсов (рисунок 2.4.П): действия из раз- 
дела «приготовления» нужно выполнить один раз (а потом просто выполнять 
тест-кейсы), а сами тест-кейсы можно выполнять в любом порядке. 

e Набор изолированных последовательных тест-кейсов (рисунок 2.4.1): дей- 
ствия из раздела «приготовления» нужно повторить перед каждым тест-кей- 
сом, а сами тест-кейсы нужно выполнять в строго определённом порядке. 

e Набор обобщённых последовательных тест-кейсов (рисунок 2.4.]): действия 
из раздела «приготовления» нужно выполнить один раз (а потом просто вы- 
полнять тест-кейсы), а сами тест-кейсы нужно выполнять в строго опреде- 
лённом порядке. 





303 «Ап Introduction to Scenario Testing», Сет Kaner [http://www.kaner.com/pdfs/ScenariolntroVer4.pdf] 
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Главное преимущество изолированности: каждый тест-кейс выполняется в 
«чистой среде», на него не влияют результаты работы предыдущих тест-кейсов. 

Главное преимущество обобщённости: приготовления не нужно повторять 
(экономия времени). 

Главное преимущество последовательности: ощутимое сокращение шагов в 
каждом тест-кейсе, т.к. результат выполнения предыдущего тест-кейса является 
начальной ситуацией для следующего. 

Главное преимущество свободы: возможность выполнять тест-кейсы в лю- 
бом порядке, а также то, что при провале некоего тест-кейса (приложение не при- 
шло в ожидаемое состояние) остальные тест-кейсы по-прежнему можно выполнять. 





Рисунок 2.4.0 — Набор изолированных свободных тест-кейсов 


Приготовления 





Рисунок 2.4.1 — Набор обобщённых свободных тест-кейсов 
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Приготовления 


Рисунок 2.4.1 — Набор изолированных последовательных тест-кейсов 


Приготовления 








Рисунок 2.4.] — Набор обобщённых последовательных тест-кейсов 


Принципы построения наборов тест-кейсов 


Теперь — о самом главном: как формировать наборы тест-кейсов. Правиль- 
ный ответ звучит очень кратко: логично. И это не шутка. Единственная задача набо- 
ров — повысить эффективность тестирования за счёт ускорения и упрощения вы- 
полнения тест-кейсов, увеличения глубины исследования некоей области приложе- 
ния или функциональности, следования типичным пользовательским сценариям “3 
или удобной последовательности выполнения тест-кейсов и т.д. 

Набор тест-кейсов всегда создаётся с какой-то целью, на основе какой-то ло- 
гики, и по этим же принципам в набор включаются тесты, обладающие подходя- 
щими свойствами. 

Если же говорить о наиболее типичных подходах к составлению наборов 
тест-кейсов, то можно обозначить следующее: 

e На основе чек-листов. Посмотрите внимательно на примеры чек-листов!'', 
которые мы разработали в соответствующем разделе!!2: каждый пункт чек- 
листа может превратиться в несколько тест-кейсов — и вот мы получаем го- 
товый набор. 
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e На основе разбиения приложения на модули и подмодули!?2. Для каждого 
модуля (или его отдельных подмодулей) можно составить свой набор тест- 
кейсов. 

• По принципу проверки самых важных, менее важных и всех остальных функ- 
ций приложения (именно по этому принципу мы составляли примеры чек-ли- 
стов!"13)). 

• По принципу группировки тест-кейсов для проверки некоего уровня требова- 
ний или типа требований, группы требований или отдельного требования. 

• По принципу частоты обнаружения тест-кейсами дефектов в приложении 
(например, мы видим, что некоторые тест-кейсы раз за разом завершаются 
неудачей, значит, мы можем объединить их в набор, условно названный 
«проблемные места в приложении»). 

e По архитектурному принципу (см. «многоуровневая архитектура» ' самосто- 
ятельно): наборы для проверки пользовательского интерфейса и всего 
уровня представления, для проверки уровня бизнес-логики, для проверки 
уровня данных. 

e По области внутренней работы приложения, например: «тест-кейсы, затра- 
гивающие работу с базой данных», «тест-кейсы, затрагивающие работу с 
файловой системой», «тест-кейсы, затрагивающие работу с сетью», и т.д. 

e По видам тестирования (см. главу «Подробная классификация тестирова- 
ния»). 


Не нужно заучивать этот список. Это всего лишь примеры — грубо говоря, 
«первое, что приходит в голову». Важен принцип: если вы видите, что выполнение 
некоторых тест-кейсов в виде набора принесёт вам пользу, создавайте такой набор. 

Примечание: без хороших инструментальных средств управления тест-кей- 
сами работать с наборами тест-кейсов крайне тяжело, т.к. приходится самостоя- 
тельно следить за приготовлениями, «недостающими шагами», изолированностью 
или обобщённостью, свободностью или последовательностью и т.д. 
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2.4.7. Логика создания эффективных проверок 


Теперь, когда мы рассмотрели принципы построения чек-листов!''2 иоформ- 
ления тест-кейсов!2?, свойства качественных тест-кейсов'з3, а также принципы объ- 
единения тест-кейсов в наборы, настало время перейти к самой сложной, «фи- 
лософской» части, в которой мы будем рассуждать уже не о том, что и как писать, 
а о том, как думать. 

Ранее уже было сказано: если у тест-кейса не указаны входные данные, 
условия выполнения и ожидаемые результаты, и/или не ясна цель тест-кейса — 
это плохой тест-кейс. И здесь во главе угла стоит цель. Если мы чётко понимаем, 
что и зачем мы делаем, мы или быстро находим всю остальную недостающую ин- 
формацию, или столь же быстро формулируем правильные вопросы и адресуем их 
правильным людям. 


Вся суть работы тестировщика в конечном итоге направлена на повышение 
качества (процессов, продуктов ит.д.). Но что такое качество? Да, существует сухое 
официальное определениез““, но даже там сказано про «иѕег/сиѕіотег needs апа 
expectations» (потребности и ожидания пользователя/заказчика). 

И здесь проявляется главная мысль: качество — это некая ценность для 
конечного пользователя (заказчика). Человек в любом случае платит за исполь- 
зование продукта — деньгами, своим временем, какими-то усилиями (даже если вы 
не получаете эту «оплату», человек вполне обоснованно считает, что что-то уже на 
вас потратил, и он прав). Но получает ли он то, на что рассчитывал (предположим, 
что его ожидания — здравы и реалистичны)? 

Если мы подходим к тестированию формально, мы рискуем получить про- 
дукт, который по документам (метрикам и т.д.) выглядит идеально, но в реальности 
никому не нужен. 

Поскольку практически любой современный программный продукт представ- 
ляет собой непростую систему, среди широкого множества её свойств и функций 
объективно есть самые важные, менее важные и совсем незначительные по важ- 
ности для пользователей. 

Если усилия тестировщиков будут сконцентрированы на первой и второй ка- 
тегории (самом важном и чуть менее важном), наши шансы создать приложение, 
удовлетворяющее заказчика, резко увеличиваются. 


Есть простая логика: 

• Тесты ищут ошибки. 

• Но все ошибки найти невозможно. 

e Значит, наша задача — найти максимум ВАЖНЫХ ошибок за имеющееся 
время. 


Под важными ошибками здесь мы понимаем такие, которые приводят к нару- 
шению важных для пользователя функций или свойств продукта. Функции и свой- 
ства разделены не случайно — безопасность, производительность, удобство ит.д. 
не относятся к функциям, но играют ничуть не менее важную роль в формировании 
удовлетворённости заказчика и конечных пользователей. 

Ситуация усугубляется следующими фактами: 

e в силу множества экономических и технических причин мы не можем выпол- 
нить «все тесты, что придут нам в голову» (да ещё и многократно) — прихо- 
дится тщательно выбирать, что и как мы будем тестировать, принимая во 
внимание только что упомянутую мысль: качество — это некая ценность для 
конечного пользователя (заказчика); 





304 Quality. Тһе degree їо which а component, system ог process meets specified requirements and/or иѕег/сиѕіотег needs апа 
expectations. [ISTQB Glossary] 
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никогда в реальной жизни (как бы мы ни старались) мы не получим «совер- 
шенного и идеального набора требований» — там всегда будет некоторое 
количество недоработок, и это тоже надо принимать во внимание. 


Однако существует достаточно простой алгоритм, позволяющий нам созда- 


вать эффективные проверки даже в таких условиях. Приступая к продумыванию 
чек-листа, тест-кейса или набора тест-кейсов, задайте себе следующие вопросы и 
получите чёткие ответы: 


Что перед вами? Если вы не понимаете, что вам предстоит тестировать, вы 
не уйдёте дальше бездумных формальных проверок. 

Кому и зачем оно нужно (и насколько это важно)? Ответ на этот вопрос поз- 
волит вам быстро придумать несколько характерных сценариев использова- 
ния!“ того, что вы собираетесь тестировать. 

Как оно обычно используется? Это уже детализация сценариев и источник 
идей для позитивного тестирования?» (их удобно оформить в виде чек-ли- 
ста). 

Как оно может сломаться, т.е. начать работать неверно? Это также детали- 
зация сценариев использования, но уже в контексте негативного тестирова- 
ния) (их тоже удобно оформить в виде чек-листа). 


К этому алгоритму можно добавить ещё небольшой перечень универсальных 


рекомендаций, которые позволят вам проводить тестирование лучше: 


Начинайте как можно раньше — уже с момента появления первых требова- 
ний можно заниматься их тестированием и улучшением, можно писать чек- 
листы и тест-кейсы, можно уточнять план тестирования, готовить тестовое 
окружение и т.д. 

Если вам предстоит тестировать что-то большое и сложное, разбивайте его 
на модули и подмодули, функциональность подвергайте функциональной 
декомпозицииз% — т.е. добейтесь такого уровня детализации, при котором 
вы можете без труда удержать в голове всю информацию об объекте тести- 
рования. 

Обязательно пишите чек-листы. Если вам кажется, что вы сможете запом- 
нить все идеи и потом легко их воспроизвести, вы ошибаетесь. Исключений 
не бывает. 

По мере создания чек-листов, тест-кейсов и т.д. прямо в текст вписывайте 
возникающие вопросы. Когда вопросов накопится достаточно, соберите их 
отдельно, уточните формулировки и обратитесь к тому, кто может дать от- 
веты. 

Если используемое вами инструментальное средство позволяет использо- 
вать косметическое оформление текста — используйте (так текст будет 
лучше читаться), но старайтесь следовать общепринятым традициям и не 
раскрашивать каждое второе слово в свой цвет, шрифт, размер и т.д. 
Используйте технику беглого просмотра“ для получения отзыва от коллег и 
улучшения созданного вами документа. 

Планируйте время на улучшение тест-кейсов (исправление ошибок, дора- 
ботку по факту изменения требований и т.д.). 

Начинайте проработку (и выполнение) тест-кейсов с простых позитивных 
проверок наиболее важной функциональности. Затем постепенно повы- 
шайте сложность проверок, помня не только о позитивных“, но и о негатив- 
ных” проверках. 





305 «Functional decomposition», Wikipedia [http://en.wikipedia.org/wiki/Functional_decomposition] 
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• Помните, что в основе тестирования лежит цель. Если вы не можете быстро 
и просто сформулировать цель созданного вами тест-кейса, вы создали пло- 
хой тест-кейс. 

• Избегайте избыточных, дублирующих друг друга тест-кейсов. Минимизиро- 
вать их количество вам помогут техники классов эквивалентности", гранич- 
ных условий, доменного тестирования? 

e Если показательность"з?” тест-кейса можно увеличить, при этом не сильно 
изменив его сложность и не отклонившись от исходной цели, сделайте это. 

• Помните, что очень многие тест-кейсы требуют отдельной подготовки, кото- 
рую нужно описать в соответствующем поле тест-кейса. 

e Несколько позитивных тест-кейсов7? можно безбоязненно объединять, но 
объединение негативных тест-кейсов7° почти всегда запрещено. 

• Подумайте, как можно оптимизировать созданный вами тест-кейс (набор 
тест-кейсов и т.д.) так, чтобы снизить трудозатраты на его выполнение. 

e Перед тем как отправлять финальную версию созданного вами документа, 
ещё раз перечитайте написанное (в доброй половине случаев найдёте опе- 
чатку или иную недоработку). 


адание 2.4.е: дополните этот список идеями, которые вы почерпнули из 
ругих книг, статей и т.д. 







Пример реализации логики создания эффективных проверок 


Ранее мы составили подробный чек-лист!!'2! для тестирования нашего «Кон- 
вертера файлов»?”. Давайте посмотрим на него критически и подумаем: что можно 
сократить, чем мы в итоге пожертвуем и какой выигрыш получим. 

Прежде чем мы начнём оптимизировать чек-лист, важно отметить, что реше- 
ние о том, что важно и что неважно, стоит принимать на основе ранжирования тре- 
бований по важности, а также согласовывать с заказчиком. 

Что для пользователя САМОЕ важное? Ради чего создавалось приложение? 
Чтобы конвертировать файлы. Принимая во внимание тот факт, что настройку при- 
ложения будет выполнять квалифицированный технический специалист, мы можем 
даже «отодвинуть на второй план» реакцию приложения на ошибки стадии запуска 
и завершения. 


И на первое место выходит: 
• Обработка файлов, разные форматы, кодировки и размеры: 
Таблица 2.4.4 — Форматы, кодировки и размеры файлов 






































Форматы входных файлов 
TXT HTML MD 
WIN1251 100 КБ 50 MB 10 MB 
CP866 10 MB 100 КБ 50 MB 
Кодировки KOI8R 50 MB 10 MB 100 KB 
входных фай- Любая 0 байт 
лов Любая 50 МБ +1Б 50 МБ +1 Б 50 МБ +1Б 
= Любой недопустимый формат 
Любая Повреждения в допустимом формате 
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Можем ли мы как-то ускорить выполнение этих проверок (ведь их много)? 


Можем. И у нас даже есть два взаимодополняющих инструмента: 


дальнейшая классификация по важности; 
автоматизация тестирования. 


Сначала поделим таблицу на две — чуть более важное и чуть менее важное. 
В «чуть более важное» попадает: 


Таблица 2.4.е — Форматы, кодировки и размеры файлов 




















Форматы входных файлов 
ТХТ HTML MD 
Кодировки | WIN1251 100 KB 50 MB 10 MB 
входных фай- | CP866 10 МБ 100 КБ 50 МБ 
лов KOI8R 50 MB 10 MB 100 KB 

















Подготовим 18 файлов — 9 исходных + 9 сконвертированных (в любом mek- 


стовом редакторе с функцией конвертации кодировок), чтобы в дальнейшем 
сравнивать работу нашего приложения с эталоном. 


Для «чуть менее важного» осталось: 

Файл размером 0 байт (объективно для него не важна такая характеристика, 
как «кодировка»). Подготовим один файл размером 0 байт. 

Файл размером 50 МБ + 1 Б (для него тоже не важна кодировка). Подготовим 
один файл размером 52'428'801 байт. 

Любой недопустимый формат: 

о По расширению (файл с расширением, отличным от txt, .html, .md). 
Берём любой произвольный файл, например картинку (размер от 1 
до 50 МБ, расширение ./рд). 

о По внутреннему содержанию (например, .јро переименовали в .txt). Ko- 
nuu файла из предыдущего пункта даём расширение .txt. 

Повреждения в допустимом формате. Вычёркиваем. Вообще. Даже крайне 
сложные дорогие редакторы далеко не всегда способны восстановить по- 
вреждённые файлы своих форматов, наше же приложение — это просто 
миниатюрная утилита конвертации кодировок, и не стоит ждать от неё 
возможностей профессионального инструментального средства восста- 
новления данных. 


Что мы получили в итоге? Нам нужно подготовить следующие 22 файла (по- 


скольку у файлов всё равно есть имена, усилим этот набор тестовых данных, пред- 
ставив в именах файлов символы латиницы, кириллицы и спецсимволы). 
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Таблица 2.4.1 — Итоговый набор файлов для тестирования приложения 



















































































№ Имя Кодировка Размер 
1 «Мелкий» файл в WIN1251.txt WIN1251 100 KB 
2 | «Средний» файл в CP866.txt СР866 10 МБ 
3 | «Крупный» файл в KOI8R.txt КО!8В 50 МБ 
4 | «Крупный» файл в win-1251.html WIN1251 50 МБ 
5 | «Мелкий» файл в cp-866.html СР866 100 КБ 
6 | «Средний» файл в Ко!8-г. Пт! KOI8R 10 MB 
7 | «Средний» файл в WIN_1251.md WIN1251 10 MB 
8 | «Крупный» файл в СР_866.та СР866 50 МБ 
9 | «Мелкий» файл в КОІ8 В.та KOI8R 100 KB 
10 | «Мелкий» эталон WIN1251.txt UTF8 100 KB 
11 | «Средний» эталон CP866.txt ОТЕ8 10 МБ 
12 | «Крупный» эталон KOI8R.txt ОТЕ8 50 МБ 
13 | «Крупный» эталон в win-1251.html ОТЕ8 50 МБ 
14 | «Мелкий» эталон в ср-866.ћіті ОТЕ8 100 КБ 
15 | «Средний» эталон в koi8-r.html UTF8 10 MB 
16 | «Средний» эталон B WIN_1251.md UTF8 10 MB 
17 | «Крупный» эталон в СР_866.та ОТЕ8 50 МБ 
18 | «Мелкий» эталон в КО!8_В.та UTF8 100 КБ 
19 | Пустой файл.та = 05 

20 | Слишком большой файл.іхї - 52'428'801 Б 
21 | Картинка.јро И ~ 1 МБ 
22 | Картинка в виде TXT.txt - ~ 1 МБ 








И только что мы упомянули автоматизацию как способ ускорения выполне- 
ния тест-кейсов. В данном случае мы можем обойтись самыми тривиальными ко- 
мандными файлами. В приложении «Командные файлы для Windows и Linux, авто- 
матизирующие выполнение дымового тестирования» 2! приведены скрипты, NON- 
ностью автоматизирующие выполнение всего уровня дымового тестирования? над 
представленным выше набором из 22 файлов. 





Задание 2.4.1: доработайте представленные в приложении? командные | 


чә файлы так, чтобы их выполнение заодно проверяло работу тестируемого | 
| приложения с пробелами, кириллическими символами и спецсимволами в | 
путях к входному каталогу, выходному каталогу и файлу журнала. Опти- | 
’ мизируйте получившиеся командные файлы так, чтобы избежать много- ' 





Если снова вернуться к чек-листу, то оказывается, что мы уже подготовили 
проверки для всего уровня дымового тестирования? и части уровня тестирования 
критического пути”. 

Продолжим оптимизацию. Большинство проверок не представляет особой 
сложности, и мы разберёмся с ними по ходу дела, но есть в чек-листе пункт, вызы- 
вающий особую тревогу: производительность. 

Тестирование и оптимизация производительности — это отдельный вид 
тестирования со своими достаточно непростыми правилами и подходами, к тому 
же разделяющийся на несколько подвидов. Нужно ли оно нам в нашем приложе- 
нии? Заказчик в АК-1.1 определил минимальную производительность приложения 
как способность обрабатывать входные данные со скоростью не менее 5 МБ/сек. 
Грубые эксперименты на указанном в АК-1.1 оборудовании показывают, что даже 
куда более сложные операции (например, архивирование видеофайла с макси- 
мальной степенью сжатия) выполняются быстрее (пусть и ненамного). Вывод? Вы- 
чёркиваем. Вероятность встретить здесь проблему ничтожно мала, а соответству- 
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ющее тестирование требует ощутимых затрат сил и времени, а также наличия со- 
ответствующих специалистов. 


Вернёмся к чек-листу: 


• Конфигурирование и запуск: 





= Значения ЅООВСЕ рів DESHNA HON-DR—OG-FHE-NAME 


7 
O 
CrIc D >, 
о 
















верки работы приложения с 22 файлами.) 
= Значение -Об-ЕШЕ МАМЕ не-указано: (Объединить с npo- 


веркой ведения самого файла журнала.) 
о Без параметров. 
о С недостаточным количеством параметров. 
о С неверными параметрами: 
= Недопустимый путь ЅООКСЕ БІК. 
= Недопустимый путь DESTINATION_DIR. 
= Недопустимое имя ОС ЕЕ МАМЕ. 
= DESTINATION_DIR находится внутри SOURCE_DIR. 
" Значения DESTINATION_DIR и SOURCE_DIR совпадают. 
e Обработка файлов: 
о Разные ферматьь кодировки и-размеры- (Уже сделано.) 
о Недоступные входные файлы: 
= Нет прав доступа. 
= Файл открыт и заблокирован. 
" Файл с атрибутом «только для чтения». 
e— Остановка: 


о окна-конеели. (Вычёркиваем. Не настолько важная npo- 
верка, а если и будут проблемы — технология РНР не позволит 
их решить.) 

e Журнал работы приложения: 


о Автоматическое создание (при отсутствии журнала), имя журнала ука- 
зано явно. 
о Продолжение (дополнение журнала) при повторных запусках, имя жур- 
нала не указано. 
ә__Нреиәвәдитеғьнеет- 
о Элементарный -тест-с-ғрубой-оценкой: (Ранее решили, что наше npn- 


ложение явно уложится в весьма демократичные требования за- 
казчика.) 








Перепишем компактно то, что у нас осталось от уровня тестирования крити- 
ческого пути”. Внимание! Это — НЕ тест-кейс! Это всего лишь ещё одна форма 
записи чек-листа, более удобная на данном этапе. 
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Таблица 2.4.0 — Чек-лист для уровня критического пути 














Суть проверки Ожидаемая реакция 

Запуск без параметров. Отображение инструкции к использованию. 
Запуск с недостаточным количеством парамет- | Отображение инструкции к использованию и 
ров. указание имён недостающих параметров. 
Запуск с неверными значениями параметров: Отображение инструкции к использованию и 
о Недопустимый путь SOURCE_DIR. указание имени неверного параметра, значе- 
о Недопустимый путь DESTINATION_DIR. ния неверного параметра и пояснения сути 
о Недопустимое имя ОС ЕШЕ_ МАМЕ. проблемы. 
о РЕЅТІМАТІОМ ВІВ находится внутри 

SOURCE_DIR. 


о Значения DESTINATION_DIR n 
SOURCE_DIR совпадают. 








Недоступные входные файлы: Отображение сообщения в консоль и файл 

о Нет прав доступа. журнала, дальнейшее игнорирование недо- 

о Файл открыт и заблокирован. ступных файлов. 

о _ Файл с атрибутом «только для чтения». 

Журнал работы приложения: Создание или продолжение ведения файла 

о Автоматическое создание (при отсутствии | журнала по указанному или вычисленному 
журнала), имя журнала указано явно. пути. 


о Продолжение (дополнение журнала) при 
повторных запусках, имя журнала не ука- 
зано. 














Наконец, у нас остался уровень расширенного тестирования??. И сейчас мы 
сделаем то, чего по всем классическим книгам учат не делать, — мы откажемся от 
всего этого набора проверок целиком. 





——_ Значения ЗОВ СЕ DIR, Е е, эбизе ЕЕ МАМЕ: 











+ _106-РГЕ МАМЕ внутри ЅОЦВСЕ ВІВ. 
ө-— Размер ГОС—ЕНЕ-МАМЕ на момент запуска: 

+_2_4 Б. 

*__4+-Б. 








о 


7 Одинәковыми sapamerpanm SOURCE- РІВ; РЕЅМАЋОМ-ВІВ; 


г шкын КЕ ДЕШЕ но-разными 
БВЕЗАИМАТЮМ ВІВ. 
+__Одинаковыми-РЕЅ5ҸАЋОМ-ВІВ-и--ОС- ЯШЕ МАМЕ; нө-раз- 

















Да, мы сейчас действительно повысили риск пропустить какой-то дефект. Но 
— дефект, вероятность возникновения которого мала в силу малой вероятности 
возникновения описанных в этих проверках ситуаций. При этом по самым скромным 
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прикидкам мы на треть сократили общее количество проверок, которые нам нужно 
будет выполнять, а значит — высвободили силы и время для более тщательной 
проработки типичных каждодневных сценариев использования!“ приложения. 


Весь оптимизированный чек-лист (он же — и черновик для плана выполнения 
проверок) теперь выглядит так: 


1) Подготовить файлы (см. таблицу 2.4.1). 

2) Для «дымового теста» использовать командные файлы (см. приложение «Ко- 
мандные файлы для Windows и Linux, автоматизирующие выполнение дымо- 
вого тестирования» '?1}), 

3) Для основных проверок использовать файлы из пункта 1 и следующие идеи 
(таблица 2.4.һ). 


Таблица 2.4.һ — Основные проверки для приложения «Конвертер файлов» 





Суть проверки 


Ожидаемая реакция 





Запуск без параметров. 


Отображение инструкции к использованию. 





Запуск с недостаточным количеством парамет- 
ров. 


Отображение инструкции к использованию и 
указание имён недостающих параметров. 





Запуск с неверными значениями параметров: 
о Недопустимый путь SOURCE_DIR. 


Отображение инструкции к использованию и 
указание имени неверного параметра, значе- 


ния неверного параметра и пояснения сути 
проблемы. 


о Недопустимый путь ОЕЅТІМАТІОМ ВІК. 

о Недопустимое имя ОС ЕШЕ_ МАМЕ. 

о РЕЅТІМАТІОМ ВІА находится внутри 
SOURCE_DIR. 

о Значения DESTINATION_DIR n 
SOURCE_DIR совпадают. 

Недоступные входные файлы: 

о Нет прав доступа. 

о Файл открыт и заблокирован. 

о Файл с атрибутом «только для чтения». 

Журнал работы приложения: 

о Автоматическое создание (при отсутствии 
журнала), имя журнала указано явно. 

о Продолжение (дополнение журнала) при по- 
вторных запусках, имя журнала не указано. 





Отображение сообщения в консоль и файл 
журнала, дальнейшее игнорирование недо- 
ступных файлов. 





Создание или продолжение ведения файла 
журнала по указанному или вычисленному 
пути. 














4) В случае наличия времени использовать первоначальную редакцию чек-ли- 
ста для уровня расширенного тестирования?® как основу для выполнения NC- 
следовательского тестирования?2. 


И почти всё. Остаётся только ещё раз подчеркнуть, что представленная ло- 
гика выбора проверок не претендует на то, чтобы считаться единственно верной, 
но она явно позволяет сэкономить огромное количество усилий, при этом практи- 
чески не снизив качество тестирования наиболее востребованной заказчиком функ- 
циональности приложения. 


Задание 2.4.9: подумайте, какие проверки из таблицы 2.4.П можно авто- 
_ матизировать с помощью командных файлов. Напишите такие командные 
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2.4.8. Типичные ошибки при разработке чек-листов, тест-кейсов и 
наборов тест-кейсов 


Ошибки оформления и формулировок 


Отсутствие заглавия тест-кейса или плохо написанное заглавие. В абсо- 
лютном большинстве систем управления тест-кейсами поле для заглавия вынесено 
отдельно и является обязательным к заполнению — тогда эта проблема отпадает. 
Если же инструментальное средство позволяет создать тест-кейс без заглавия, 
возникает риск получить М тест-кейсов, для понимания сути каждого из которых 
нужно прочитать десятки строк вместо одного предложения. Это гарантированное 
убийство рабочего времени и снижение производительности команды на порядок. 

Если заглавие тест-кейса приходится вписывать в поле с шагами и инстру- 
ментальное средство допускает форматирование текста, заглавие стоит писать 
жирным шрифтом, чтобы его было легче отделять от основного текста. 

Продолжением этой ошибки является создание одинаковых заглавий, по ко- 
торым объективно невозможно отличить один тест-кейс от другого. Более того, воз- 
никает подозрение, что одинаково озаглавленные тест-кейсы и внутри одинаковы. 
Потому следует формулировать заглавия по-разному, при этом подчёркивая в них 
суть тест-кейса и его отличие от других, похожих тест-кейсов. 

И, наконец, в заглавии недопустимы «мусорные слова» вида «проверка», 
«тест» и т.д. Ведь это заглавие тест-кейса, т.е. речь по определению идёт о про- 
верке, и не надо этот факт подчёркивать дополнительно. Также см. более подроб- 
ное пояснение этой ошибки ниже в пункте «Постоянное использование слов «про- 
верить» (и ему подобных) в чек-листах». 


Отсутствие нумерации шагов и/или ожидаемых результатов (даже если 
таковой всего лишь один). Наличие этой ошибки превращает тест-кейс в «поток со- 
знания», в котором нет структурированности, модифицируемости и прочих nones- 
ных свойств (да, многие свойства качественных требований“? в полной мере npn- 
менимы и к тест-кейсам) — становится очень легко перепутать, что к чему отно- 
сится. Даже выполнение такого тест-кейса усложняется, а доработка и вовсе пре- 
вращается в каторжный труд. 


Ссылка на множество требований. Иногда высокоуровневый тест-кейси!” 
действительно затрагивает несколько требований, но в таком случае рекоменду- 
ется писать ссылку на максимум 2-3 самых ключевых (наиболее соответствующих 
цели тест-кейса), а ещё лучше — указывать общий раздел этих требований (т.е. не 
ссылаться, например, на требования 5.7.1, 5.7.2, 5.7.3, 5.7.7, 5.7.9, 5.7.12, а просто 
сослаться на раздел 5.7, включающий в себя все перечисленные пункты). В боль- 
шинстве инструментальных средств управления тест-кейсами это поле представ- 
ляет собой выпадающий список, и там эта проблема теряет актуальность. 


Использование личной формы глаголов. Если вы пишете требования на 
русском, то пишите «нажать» вместо «нажмите», «ввести» вместо «введите», «пе- 
рейти» вместо «перейдите» и т.д. В технической документации вообще не рекомен- 
дуется «переходить на личности», а также существует мнение, что личная форма 
глаголов подсознательно воспринимается как «чужие бессмысленные команды» и 
приводит к повышенной утомляемости и раздражительности. 


Использование прошедшего или будущего времени в ожидаемых ре- 
зультатах. Это не очень серьёзная ошибка, но всё равно «введённое значение 
отображается в поле» читается лучше, чем «введённое значение отобразилось в 
поле» или «введённое значение отобразится в поле». 
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Постоянное использование слов «проверить» (и ему подобных) в чек- 
листах. В итоге почти каждый пункт чек-листа начинается с «проверить ...», «про- 
верить...», «проверить...». Но ведь весь чек-лист — это и есть список проверок! 
Зачем писать это слово? Сравните: 

















Плохо Хорошо 
Проверить запуск приложения. Запуск приложения. 
Проверить открытие корректного файла. Открытие корректного файла. 
Проверить модификацию файла. Модификация файла. 
Проверить сохранение файла. Сохранение файла. 
Проверить закрытие приложения. Закрытие приложения. 





Сюда же относится типичное слово «попытаться» в негативных тест-кейсах 
(«попытаться поделить на ноль», «попытаться открыть несуществующий файл», 
«попытаться ввести недопустимые символы»): «деление на ноль», «открытие не- 
существующего файла», «ввод спецсимволов» намного короче и информативнее. 
А реакцию приложения, если она не очевидна, можно указать в скобках (так будет 
даже информативнее): «деление на ноль» (сообщение «Division Бу zero detected»), 
«открытие несуществующего файла» (приводит к автоматическому созданию 
файла), «ввод спецсимволов» (символы не вводятся, отображается подсказка). 


Описание стандартных элементов интерфейса вместо использования 
их устоявшихся названий. «Маленький крестик справа вверху окна приложения» 
— это системная кнопка «Закрыть» (system button «С1озе»), «быстро-быстро ABa- 
жды нажать на левую клавишу мыши» — это двойной щелчок (double click), «ма- 
ленькое окошечко с надписью появляется, когда наводишь мышь» — это всплыва- 
ющая подсказка (һїпї). 


Пунктуационные, орфографические, синтаксические и им подобные 
ошибки. Без комментариев. 


Логические ошибки 


Ссылка на другие тест-кейсы или шаги других тест-кейсов. За исключе- 
нием случаев написания строго оговорённого явно обозначенного набора последо- 
вательных тест-кейсов‘ “3 это запрещено делать. В лучшем случае вам повезёт, и 
тест-кейс, на который вы ссылались, будет просто удалён — повезёт потому, что 
это будет сразу заметно. Не повезёт в случае, если тест-кейс, на который вы ссы- 
лаетесь, будет изменён — ссылка по-прежнему ведёт в некое существующее ме- 
сто, но описано там уже совершенно не то, что было в момент создания ссылки. 


Детализация, не соответствующая уровню функционального тестиро- 
вания“. Например, не нужно на уровне дымового тестирования?“ проверять pa- 
ботоспособность каждой отдельной кнопки или прописывать некий крайне слож- 
ный, нетривиальный и редкий сценарий — поведение кнопок и без явного указания 
будет проверено множеством тест-кейсов, объективно задействующих эти кнопки, 
а сложному сценарию место на уровне тестирования критического пути” или даже 
на уровне расширенного тестирования? (в которых, напротив, недостатком можно 
считать излишнее обобщение без должной детализации). 
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Расплывчатые двусмысленные описания действий и ожидаемых ре- 
зультатов. Помните, что тест-кейс с высокой вероятностью будете выполнять не 
вы (автор тест-кейса), а другой сотрудник, и он — не телепат. Попробуйте дога- 
даться по этим примерам, что имел в виду автор: 

• «Установить приложение на диск С». (Т.е. в «С:\»? Прямо в корень? Или как?) 
• «Нажать на иконку приложения». (Например, если у меня есть ісо-файл с 
иконкой приложения, и я по нему кликну — это оно? Или нет?) 
«Окно приложения запустится». (Куда?) 
«Работает верно». (Ого! А верно — это, простите, как?) 
«ОК». (И? Что «ОК»?) 
«Количество найденных файлов совпадает». (С чем?) 
«Приложение отказывается выполнять команду». (Что значит «отказыва- 
ется»? Как это выглядит? Что должно происходить?) 


Описание действий в качестве наименований модуля/подмодуля. 
Например, «запуск приложения» — это НЕ модуль или подмодуль. Модуль или под- 
модуль"? — это всегда некие части приложения, а не его поведение. Сравните: 
«дыхательная система» — это модуль человека, но «дыхание» — нет. 


Описание событий или процессов в качестве шагов или ожидаемых ре- 
зультатов. Например, в качестве шага сказано: «Ввод спецсимволов в поле Х». 
Это было бы сносным заглавием тест-кейса, но не годится в качестве шага, который 
должен быть сформулирован как «Ввести спецсимволы (перечень) в поле Х». 

Куда страшнее, если подобное встречается в ожидаемых результатах. 
Например, там написано: «Отображение скорости чтения в панели Х». И что? Оно 
должно начаться, продолжиться, завершиться, не начинаться, неким образом из- 
мениться (например, измениться должна размерность данных), как-то на что-то по- 
влиять? Тест-кейс становится полностью бессмысленным, т.к. такой ожидаемый 
результат невозможно сравнить с фактическим поведением приложения. 


«Выдумывание» особенностей поведения приложения. Да, часто в тре- 
бованиях отсутствуют самоочевидные (без кавычек, они на самом деле самооче- 
видные) вещи, но нередко встречаются и некачественные (например, неполные) 
требования, которые нужно улучшать, а не «телепатически компенсировать». 

Например, в требованиях сказано, что «приложение должно отображать диа- 
логовое окно сохранения с указанным по умолчанию каталогом». Если из контекста 
(соседних требований, иных документов) ничего не удаётся узнать об этом таин- 
ственном «каталоге по умолчанию», нужно задать вопрос. Нельзя просто записать 
в ожидаемых результатах «отображается диалоговое окно сохранения с указанным 
по умолчанию каталогом» (как мы проверим, что выбран именно указанный по 
умолчанию каталог, а не какой-то иной?). И уж тем более нельзя в ожидаемых ре- 
зультатах писать «отображается диалоговое окно сохранения с выбранным ката- 
логом “С:/Ѕауедароситепїѕ”» (откуда взялось это «С:/Ѕбауеароситепіѕ», — не ясно, 
т.е. оно явно выдумано из головы и, скорее всего, выдумано неправильно). 
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Отсутствие описания приготовления к выполнению тест-кейса. Часто 
для корректного выполнения тест-кейса необходимо каким-то особым образом 
настроить окружение. Предположим, что мы проверяем приложение, выполняющее 
резервное копирование файлов. Если тест выглядит примерно так, то выполняю- 
щий его сотрудник будет в замешательстве, т.к. ожидаемый результат кажется про- 
сто бредом. Откуда взялось «-200»? Что это вообще такое? 











Шаги выполнения Ожидаемые результаты 
1. Нажать на панели «Главная» кнопку «Быст- | 1. Кнопка «Быстрая дедубликация» переходит 
рая дедубликация». в утопленное состояние и меняет цвет с се- 
2. Выбрать каталог «С:/Мураїа». рого на зелёный. 
2. На панели «Состояние» в поле «Дубли- 
каты» отображается «~200». 











И совсем иначе этот тест-кейс воспринимался бы, если бы в приготовлениях 
было сказано: «Создать каталог “С:/Мураїѓа” с произвольным набором подкаталогов 
(глубина вложенности не менее пяти). В полученном дереве каталогов разместить 
1000 файлов, из которых 200 имеют одинаковые имена и размеры, но НЕ внутрен- 
нее содержимое». 


Полное дублирование (копирование) одного и того же тест-кейса на 
уровнях дымового тестирования, тестирования критического пути, расши- 
ренного тестирования. Многие идеи естественным образом развиваются от 
уровня к уровню, но они должны именно развиваться, а не дублироваться. Срав- 
ните: 











Дымовое тестиро- Тестирование критиче- Расширенное тестирование 
вание ского пути 
Плохо Запуск приложения. Запуск приложения. Запуск приложения. 
Хорошо | Запуск приложения. Запуск приложения из ко- | Запуск приложения из команд- 
мандной строки. ной строки в активном режиме. 


Запуск приложения через | Запуск приложения из команд- 
ярлык на рабочем столе. | ной строки в фоновом режиме. 
Запуск приложения через | Запуск приложения через ярлык 
меню «Пуск». на рабочем столе от имени ад- 
министратора. 

Запуск приложения через меню 
«Пуск» из списка часто запуска- 
емых приложений. 




















Слишком длинный перечень шагов, не относящихся к сути (цели) тест- 
кейса. Например, мы хотим проверить корректность одностороннего режима пе- 
чати из нашего приложения на дуплексном принтере. Сравните: 











Плохо Хорошо 
Односторонняя печать Односторонняя печать 
1. Запустить приложение. 1. Открыть любой ООСХ-файл, содержащий 
2. В меню выбрать «Файл» -> «Открыть». три и более непустых страницы. 
3. Выбрать любой ООСХ-файл, состоящий из | 2. В диалоговом окне «Настройка печати» в 
нескольких страниц. списке «Двусторонняя печать» выбрать 
4. Нажать кнопку «Открыть». «Нет». 
5. В меню выбрать «Файл» -> «Печать». 3. Произвести печать документа на принтере, 
6. В списке «Двусторонняя печать» выбрать поддерживающем двустороннюю печать. 
пункт «Нет». 
7. Нажать кнопку «Печать». 
8. Закрыть файл. 
9. Закрыть приложение. 
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Слева мы видим огромное количество действий, не относящихся непосред- 
ственно к тому, что проверяет тест-кейс. Тем более что запуск и закрытие прило- 
жения, открытие файла, работа меню и прочее или будут покрыты другими тест- 
кейсами (со своими соответствующими целями), или на самом деле являются са- 
моочевидными (логично ведь, что нельзя открыть приложением файл, если прило- 
жение не запущено) и не нуждаются в описании шагов, которые только создают 
информационный шум и занимают время на написание и прочтение. 


Некорректное наименование элементов интерфейса или их свойств. 
Иногда из контекста понятно, что автор тест-кейса имел в виду, но иногда это ста- 
новится реальной проблемой. Например, мы видим тест-кейс с заглавием «Закры- 
тие приложения кнопками "Close" и "Close мипаом"». Уже тут возникает недоумение 
по поводу того, в чём же различие этих кнопок, да и о чём вообще идёт речь. Ниже 
(в шагах тест-кейса) автор поясняет: «В рабочей панели внизу экрана нажать "Close 
window"». Ага! Ясно. Но «Close window» — это НЕ кнопка, это пункт системного KOH- 
текстного меню приложения в панели задач. 

Ещё один отличный пример: «Окно приложения свернётся в окно меньшего 
диаметра». Хм. Окно круглое? Или должно стать круглым? А, может, тут и вовсе 
речь про два разных окна, и одно должно будет оказаться внутри второго? Или, всё 
же «размер окна уменьшается» (кстати, насколько?), а его геометрическая форма 
остаётся прямоугольной? 

И, наконец, пример, из-за которого вполне можно написать отчёт о дефекте 
на вполне корректно работающее приложение: «В системном меню выбрать “Фик- 
сация расположения”». Казалось бы, что ж тут плохого? Но потом выясняется, что 
имелось в виду главное меню приложения, а вовсе не системное меню. 


Непонимание принципов работы приложения и вызванная этим некор- 
ректность тест-кейсов. Классикой жанра является закрытие приложения: тот 
факт, что окно приложения «исчезло» (сюрприз: например, оно свернулось в об- 
ласть уведомления панели задач (system tray, taskbar notification агеа)), или прило- 
жение отключило интерфейс пользователя, продолжив функционировать в фоно- 
вом режиме, вовсе не является признаком того, что оно завершило работу. 


Проверка типичной «системной» функциональности. Если только ваше 
приложение не написано с использованием каких-то особенных библиотек и техно- 
логий и не реализует какое-то нетипичное поведение, нет необходимости прове- 
рять системные кнопки, системные меню, сворачивание-разворачивание окна ит.д. 
Вероятность встретить здесь ошибку стремится к нулю. Если всё же очень хочется, 
можно вписать эти проверки как уточнения некоторых действий на уровне тестиро- 
вания критического пути”, но создавать для них отдельные тест-кейсы не нужно. 


Неверное поведение приложения как ожидаемый результат. Такое не 
допускается по определению. Не может быть тест-кейса с шагом в стиле «поделить 
на ноль» с ожидаемым результатом «крах приложения с потерей пользовательских 
данных». Ожидаемые результаты всегда описывают правильное поведение прило- 
жения — даже в самых страшных стрессовых тест-кейсах. 
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Общая некорректность тест-кейсов. Может быть вызвана множеством при- 
чин и выражаться множеством образов, но вот классический пример: 





Шаги выполнения Ожидаемые результаты 





4. Закрыть приложение нажатием АН+Е4. 
5. Выбрать в меню «Текущее состояние». 


. Приложение завершает работу. 

. Отображается окно с заголовком «Текущее 
состояние» и содержимым, соответствую- 
щим рисунку 999.99. 


ол р: 














Здесь или не указано, что вызов окна «Текущее состояние» происходит где- 
то в другом приложении, или остаётся загадкой, как вызвать это окно у завершив- 
шего работу приложения. Запустить заново? Возможно, но в тест-кейсе этого не 
сказано. 


Неверное разбиение наборов данных на классы эквивалентности. Дей- 
ствительно, иногда классы эквивалентности?! могут быть очень неочевидными. Но 
ошибки встречаются и в довольно простых случаях. Допустим, в требованиях ска- 
зано, что размер некоего файла может быть от 10 до 100 КБ (включительно). Раз- 
биение по размеру 0-9 КБ, 10-100 КБ, 101+ КБ ошибочно, т.к. килобайт не явля- 
ется неделимой единицей. Такое ошибочное разбиение не учитывает, например, 
размеры в 9.5 КБ, 100.1 КБ, 100.7 КБ ит.д. Потому здесь стоит применять неравен- 
ства: 0 КБ < размер < 10 КБ, 10 КБ < размер < 100 КБ, 100 КБ < размер. Также 
можно писать с использованием синтаксиса скобок: [0, 10) КБ, [10, 100] КБ, (100, о) 
КБ, но вариант с неравенствами более привычен большинству людей. 


Тест-кейсы, не относящиеся к тестируемому приложению. Например, 
нам нужно протестировать фотогалерею на сайте. Соответственно, следующие 
тест-кейсы никак не относятся к фотогалерее (они тестируют браузер, операцион- 
ную систему пользователя, файловый менеджер и т.д. — но НЕ наше приложение, 
ни его серверную, ни даже клиентскую часть): 

• Файл с сетевого диска. 
Файл со съёмного носителя. 
Файл, заблокированный другим приложением. 
Файл, открытый другим приложением. 
Файл, к которому у пользователя нет прав доступа. 
Вручную указать путь к файлу. 
Файл из глубоко расположенной поддиректории. 


Формальные и/или субъективные проверки. Чаще всего данную ошибку 
можно встретить в пунктах чек-листа. Возможно, у автора в голове и был чёткий и 
подробный план, но из следующих примеров совершенно невозможно понять, что 
будет сделано с приложением, и какой результат мы должны ожидать: 
«Сконвертировать». 

«Проверить метод де{Меззаде()». 
«Некорректная работа в корректных условиях». 
«Скорость». 

«Объём данных». 

«Должно работать быстро». 


В отдельных исключительных ситуациях можно возразить, что из контекста 
и дальнейшей детализации становится понятно, что имелось в виду. Но чаще всего 
никакого контекста и никакой дальнейшей детализации нет, т.е. приведённые при- 
меры оформлены как отдельные полноправные пункты чек-листа. Так — нельзя. 
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Как можно и нужно — см. в примере чек-листа'? и всём соответствующем раз- 
деле!12. 


Теперь для лучшего закрепления рекомендуется заново прочитать про 
оформление атрибутов тест-кейсов!'2", свойства качественных тест-кейсов!'з3 и ло- 
гику построения!“ качественных тест-кейсов и качественных наборов тест-кейсов. 





Тестирование программного обеспечения. Базовый курс. © ЕРАМ Systems, 2015-2021 Стр: 163/298 


Отчёты о дефектах 





2.5. Отчёты о дефектах 
2.5.1. Ошибки, дефекты, сбои, отказы и т.д. 


Упрощенный взгляд на понятие дефекта 


Далее в этой главе мы глубоко погрузимся в терминологию (она действи- 
тельно важна!), а потому начнём с очень простого: дефектом упрощённо можно счи- 
тать любое расхождение ожидаемого (свойства, результата, поведения и т.д., ко- 
торое мы ожидали увидеть) и фактического (свойства, результата, поведения ит.д., 
которое мы на самом деле увидели). При обнаружении дефекта создаётся отчёт о 
дефекте. 





Дефект — расхождение ожидаемого и фактического результата. | 
‚Ожидаемый результат — поведение системы, описанное в требованиях. | 
Фактический результат — поведение системы, наблюдаемое в процессе | 
‚ тестирования. | 


| | ВАЖНО! Эти три определения приведены в предельно упрощённой (и | 
, даже искажённой) форме с целью первичного ознакомления. Полноцен-_ 





Поскольку столь простая трактовка не покрывает все возможные формы про- 
явления проблем с программными продуктами, мы сразу же переходим к более по- 
дробному рассмотрению соответствующей терминологии. 


Расширенный взгляд на терминологию, описывающую проблемы 


Разберёмся с широким спектром синонимов, которыми обозначают про- 
блемы с программными продуктами и иными артефактами и процессами, сопут- 
ствующими их разработке. 

В силлабусе ISTQB написаноз%, что человек совершает ошибки, которые npn- 
водят к возникновению дефектов в коде, которые, в свою очередь, приводят к сбоям 
и отказам приложения (однако сбои и отказы могут возникать и из-за внешних усло- 
вий, таких как электромагнитное воздействие на оборудование и т.д.). 

Таким образом, упрощённо можно изобразить следующую схему: 


Рисунок 2.5.а — Ошибки, дефекты, сбои и отказы 





306 А human Бета сап таке ап error (mistake), which produces а defect (fault, bug) іп the program code, ог м а document. № а 
defect іп code is executed, the system тау fail to do what й should do (ог do something it shouldn't), causing а failure. Defects 
in software, systems or documents may result in failures, but not all defects do so. Defects occur because human beings are 
fallible and because there is time pressure, complex code, complexity of infrastructure, changing technologies, and/or many 
system interactions. Failures can be caused by environmental conditions as well. For example, radiation, magnetism, electronic 
fields, and pollution can cause faults in firmware or influence the execution of software by changing the hardware conditions. 
[ISTQB Syllabus] 
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Если же посмотреть на англоязычную терминологию, представленную в 
глоссарии ISTQB и иных источниках, можно построить чуть более сложную схему: 


Defect 
Error (Mistake) (Problem, Bug, 
Fault) 


Failure, 
Interruption 


Anomaly, Incident (Deviation) 





Рисунок 2.5.6 — Взаимосвязь проблем в разработке программных продуктов 


Рассмотрим все соответствующие термины. 





Этот термин очень часто используют как наиболее универсальный, описыва- 
ющий любые проблемы («ошибка человека», «ошибка в коде», «ошибка в докумен- 
тации», «ошибка выполнения операции», «ошибка передачи данных», «ошибочный 
результат» и т.п.) Более того, куда чаще вы сможете услышать «отчёт об ошибке», 
чем «отчёт о дефекте». И это нормально, так сложилось исторически, к тому же 


термин «ошибка» на самом деле очень широкий. 


ефект (defectes, bug, problem, fault) — недостаток в компоненте или си- 
теме, способный привести к ситуации сбоя или отказа. 







Этот термин также понимают достаточно широко, говоря о дефектах в доку- 
ментации, настройках, входных данных ит.д. Почему глава называется именно «от- 
чёты о дефектах»? Потому что этот термин как раз стоит посередине — бессмыс- 
ленно писать отчёты о человеческих ошибках, равно как и почти бесполезно просто 
описывать проявления сбоев и отказов — нужно докопаться до их причины, и пер- 
вым шагом в этом направлении является именно описание дефекта. 






Сбой (іпіеггирїіопз‹) или отказ (failure?) — отклонение поведения си- 
‚ стемы от ожидаемого. | 





‚ В ГОСТ 27.002-89 даны хорошие и краткие определения сбоя и отказа: | 
Сбой — самоустраняющийся отказ или однократный отказ, устраняемый | 
незначительным вмешательством оператора. 
Отказ — событие, заключающееся в нарушении работоспособного состо- ' 





Эти термины скорее относятся к теории надёжности и нечасто встречаются 
в повседневной работе тестировщика, но именно сбои и отказы являются тем, что 
тестировщик замечает в процессе тестирования (и отталкиваясь от чего, проводит 
исследование с целью выявить дефект и его причины). 





307 Error, Mistake. А human action that produces ап incorrect result. [ISTQB Glossary] 

308 Defect, Bug, Problem, Fault. A flaw in a component or system that can cause the component or system to fail to perform its 
required function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of 
the component or system. [ISTQB Glossary] 

309 Interruption. A suspension of a process, such as the execution of a computer program, caused by an event external to that 
process and performed in such а way that the process can be resumed. [http:/www.electropedia.org/iev/iev.nsf/display?open- 
form&ievref=714-22-10] 

310 Failure. Deviation of the component or system from its expected delivery, service or result. [ISTQB Glossary] 
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Аномалия (апота!уз'") или инцидент (іпсідепіз'2, deviation) — любое oT- | 
‚ клонение наблюдаемого (фактического) состояния, поведения, значения, ' 
результата, свойства от ожиданий наблюдателя, сформированных на OC- | 
нове требований, спецификаций, иной документации или опыта и здра- 
вого смысла. | 





Итак, мы вернулись ктому, счего начинали в части этой главы, описывающей 
предельно упрощённый взгляд на дефекты. Ошибки, дефекты, сбои, отказы и т.д. 
являются проявлением аномалий — отклонений фактического результата от ожи- 
даемого. Стоит отметить, что ожидаемый результат действительно может основы- 
ваться на опыте и здравом смысле, т.к. поведение программного средства никогда 
не специфицируют до уровня базовых элементарных приёмов работы с компьюте- 
ром. 

Теперь, чтобы окончательно избавиться от путаницы и двусмысленности, до- 
говоримся, что мы будем считать дефектом в контексте данной книги: 








Дефект — отклонение (деуіайопз'2) фактического результата (actual re- 
` sults!) от ожиданий наблюдателя (expected гези!з"“), сформированных на | 
| основе требований, спецификаций, иной документации или опыта и здра- | 
' вого смысла. | 





Отсюда логически вытекает, что дефекты могут встречаться не только в коде 
приложения, но и в любой документации, в архитектуре и дизайне, в настройках 
тестируемого приложения или тестового окружения — где угодно. 





® ' Важно понимать, что приведённое определение дефекта позволяет лишь | 
® _ поднять вопрос о том, является ли некое поведение приложения дефек- | 
‚ том. В случае, если из проектной документации не следует однозначного | 
‚ положительного ответа, обязательно стоит обсудить свои выводы с KON- 
 легами и добиться донесения поднятого вопроса до заказчика, если его | 





Хорошее представление о едва-едва затронутой нами теме теории’ 
‚ надёжности можно получить, прочитав книгу Рудольфа Стапелберга | 
_ «Руководство по надёжности, доступности, ремонтопригодности и без- 
‚ опасности в инженерном проектировании» (Rudolph Frederick Stapelberg, 
«Handbook of Reliability, Availability, Maintainability апа Safety іп Engineering 
Design»). 


А краткую, но достаточно подробную классификацию аномалий в про- 
_ граммных продуктах можно посмотреть в стандарте «IEEE 1044:2009 
 Запдага Classification Рог Software Anomalies». 








311 Anomaly. Any condition that deviates from expectation based on requirements specifications, design documents, user documents, 
standards, etc. or from someone’s perception or experience. Anomalies may be found during, but not limited to, reviewing, 
testing, analysis, compilation, or use of software products or applicable documentation. See also bug, defect, deviation, error, 
fault, failure, incident, problem. [ISTQB Glossary] 

312 Incident, Deviation. Any event occurring that requires investigation. [ISTQB Glossary] 

313 Actual result. The behavior produced/observed when a component or system is tested. [ISTQB Glossary] 

314 Expected result, Expected outcome, Predicted outcome. The behavior predicted by the specification, or another source, of 
the component or system under specified conditions. [ISTQB Glossary] 





Тестирование программного обеспечения. Базовый курс. © ЕРАМ Systems, 2015-2021 Стр: 166/298 


Отчёт о дефекте и его жизненный цикл 





2.5.2. Отчёт о дефекте и его жизненный цикл 


Как было сказано в предыдущей главе, при обнаружении дефекта тестиров- 
щик создаёт отчёт о дефекте. 






тчёт о дефекте (defect герогіз') — документ, описывающий и приорити- 
 зирующий обнаруженный дефект, а также содействующий его устране- 
нию. 


Как следует из самого определения, отчёт о дефекте пишется со следую- 
щими основными целями: 

e предоставить информацию о проблеме — уведомить проектную команду и 
иных заинтересованных лиц о наличии проблемы, описать суть проблемы; 

e приоритизировать проблему — определить степень опасности проблемы для 
проекта и желаемые сроки её устранения; 

e содействовать устранению проблемы — качественный отчёт о дефекте не 
только предоставляет все необходимые подробности для понимания сути 
случившегося, но также может содержать анализ причин возникновения про- 
блемы и рекомендации по исправлению ситуации. 





На последней цели следует остановиться подробнее. Есть мнение, что «хо- 
рошо написанный отчёт о дефекте — половина решения проблемы для програм- 
миста». И действительно, как мы увидим далее (и особенно в главе «Типичные 
ошибки при написании отчётов о дефектах»), от полноты, корректности, аккурат- 
ности, подробности и логичности отчёта о дефекте зависит очень многое — одна и 
та же проблема может быть описана так, что программисту останется буквально 
исправить пару строк кода, а может быть описана и так, что сам автор отчёта на 
следующий день не сможет понять, что же он имел в виду. 






‚ ВАЖНО! «Сверхцель» написания отчёта о дефекте состоит в быстром ис- | 
‚ правлении ошибки (а в идеале — и недопущении её возникновения в 6y- 
' дущем). Потому качеству отчётов о дефекте следует уделять особое, NO- 
‹ вышенное внимание. | 


Отчёт о дефекте (и сам дефект вместе с ним) проходит определённые стадии 
жизненного цикла, которые схематично можно показать так (рисунок 2.5.с): 

e Обнаружен (submitted) — начальное состояние отчёта (иногда называется 
«Новый» (пе\м)), в котором он находится сразу после создания. Некоторые 
средства также позволяют сначала создавать черновик (draft) и лишь потом 
публиковать отчёт. 

e Назначен (assigned) — в это состояние отчёт переходит с момента, когда KTO- 
то из проектной команды назначается ответственным за исправление де- 
фекта. Назначение ответственного производится или решением лидера ко- 
манды разработки, или коллегиально, или по добровольному принципу, или 
иным принятым в команде способом или выполняется автоматически на ос- 
нове определённых правил. 

e Исправлен (fixed) — в это состояние отчёт переводит ответственный за NC- 
правление дефекта член команды после выполнения соответствующих дей- 
ствий по исправлению. 

e Проверен (verified) — в это состояние отчёт переводит тестировщик, удосто- 
верившийся, что дефект на самом деле был устранён. Как правило, такую 
проверку выполняет тестировщик, изначально написавший отчёт о дефекте. 











315 Defect report, Вид report. А document reporting оп апу flaw іп а component ог system that сап cause the component ог system 
to fail to perform its required function. [ISTQB Glossary] 
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По поводу того, должен ли проверять факт устранения дефекта 
| ‚ именно тот тестировщик, который его обнаружил, или обязательно | 


другой, есть много «священных войн». Сторонники второго вари- 
анта утверждают, что свежий взгляд человека, ранее не знакомого | 
с данным дефектом, позволяет ему в процессе верификации с. 
‚ большой вероятностью обнаружить новые дефекты. | 


_ Несмотря на то, что такая точка зрения имеет право на существо- 
‚ вание, всё же отметим: при грамотной организации процесса тести- ' 
рования поиск дефектов эффективно происходит на соответствую- _ 
щей стадии работы, а верификация силами тестировщика, обнару- | 
жившего данный дефект, всё же позволяет существенно сэконо- 
мить время. 





























Обнаружен Назначен Исправлен Проверен 








Открыт заново Закрыт 











Рекомендован к 
отклонению 



















Отклонён 


Отложен 


Рисунок 2.5.с — Жизненный цикл отчёта о дефекте с наиболее типичными перехо- 
дами между состояниями 





Набор стадий жизненного цикла, их наименование и принцип перехода от 


стадии к стадии может различаться в разных инструментальных сред- | 
| ствах управления жизненным циклом отчётов о дефектах. Более того — | 
многие такие средства позволяют гибко настраивать эти параметры. На 





e Закрыт (closed) — состояние отчёта, означающее, что по данному дефекту 
не планируется никаких дальнейших действий (хотя, конечно, ничто не ме- 
шает в будущем этому дефекту стать «открытым заново» (георепеа)). Здесь 
есть некоторые расхождения в жизненном цикле, принятом в разных инстру- 
ментальных средствах управления отчётами о дефектах: 

о В некоторых средствах существуют оба состояния — «Проверен» и 
«Закрыт», чтобы подчеркнуть, что в состоянии «Проверен» ещё могут 
потребоваться какие-то дополнительные действия (обсуждения, до- 
полнительные проверки в новых билдах и т.д.), в то время как состоя- 
ние «Закрыт» означает «с дефектом покончено, больше к этому во- 
просу не возвращаемся». 

о Внекоторых средствах одного из состояний нет (оно поглощается дру- 
гим). 
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о В некоторых средствах в состояние «Закрыт» или «Отклонён» отчёт о 
дефекте может быть переведён из множества предшествующих состо- 
яний с резолюциями наподобие: 

= «Не является дефектом» — приложение так и должно работать, 
описанное поведение не является аномальным. 
" «Дубликат» — данный дефект уже описан в другом отчёте. 
" «Не удалось воспроизвести» — разработчикам не удалось вос- 
произвести проблему на своём оборудовании. 
" «Не будет исправлено» — дефект есть, но по каким-то серьёз- 
ным причинам его решено не исправлять. 
= «Невозможно исправить» — непреодолимая причина дефекта 
находится вне области полномочий команды разработчиков, 
например существует проблема в операционной системе или 
аппаратном обеспечении, влияние которой устранить разум- 
ными способами невозможно. 
Как было только что подчёркнуто, в некоторых средствах отчёт о де- 
фекте в подобных случаях будет переведён в состояние «Закрыт», в 
некоторых — в состояние «Отклонён», в некоторых — часть случаев 
закреплена за состоянием «Закрыт», часть — за «Отклонён». 
Открыт заново (георепеа) — в это состояние (как правило, из состояния «Ис- 
правлен») отчёт переводит тестировщик, удостоверившийся, что дефект по- 
прежнему воспроизводится на билде, в котором он уже должен быть исправ- 
лен. 
Рекомендован к отклонению (to be declined) — в это состояние отчёт о де- 
фекте может быть переведён из множества других состояний с целью выне- 
сти на рассмотрение вопрос об отклонении отчёта по той или иной причине. 
Если рекомендация является обоснованной, отчёт переводится в состояние 
«Отклонён» (см. следующий пункт). 
Отклонён (declined) — в это состояние отчёт переводится в случаях, NO- 
дробно описанных в пункте «Закрыт», если средство управления отчётами о 
дефектах предполагает использование этого состояния вместо состояния 
«Закрыт» для тех или иных резолюций по отчёту. 
Отложен (deferred) — в это состояние отчёт переводится в случае, если nc- 
правление дефекта в ближайшее время является нерациональным или не 
представляется возможным, однако есть основания полагать, что в обозри- 
мом будущем ситуация исправится (выйдет новая версия библиотеки, вер- 
нётся из отпуска специалист по некоей технологии, изменятся требования 
заказчика и т.д.). 


Для полноты рассмотрения данной подтемы приведём пример жизненного 


цикла, принятого по умолчанию в инструментальном средстве управления отчё- 
тами о дефектах ЛРАз* (рисунок 2.5.4). 





316 «What is Workflow». [https://confluence.atlassian.com/jira063/what-is-workflow-683542483.html] 
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Рисунок 2.5.а — Жизненный цикл отчёта о дефекте в ЛВА 
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2.5.3. Атрибуты (поля) отчёта о дефекте 


В зависимости от инструментального средства управления отчётами о де- 
фектах внешний вид их записи может немного отличаться, могут быть добавлены 
или убраны отдельные поля, но концепция остаётся неизменной. 

Общий вид всей структуры отчёта о дефекте представлен на рисунке 2.5.е. 
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Бесконечный цикл об- 
работки входного 
файла с атрибутом 
«только для чтения» 





Если у входного файла выставлен 
атрибут «только для чтения», по- 
сле обработки приложению не уда- 
ётся переместить его в каталог- 
приёмник: создаётся копия файла, 
но оригинал не удаляется, и при- 
ложение снова и снова обрабаты- 
вает этот файл и безуспешно пы- 
тается переместить его в каталог- 
приёмник. 

Ожидаемый результат: после об- 
работки файл перемещён из ката- 
лога-источника в каталог-приём- 
ник. 

Фактический результат: обрабо- 
танный файл копируется в ката- 
лог-приёмник, но его оригинал 
остаётся в каталоге-источнике. 
Требование: ДС-2.1. 





Поместить в каталог-ис- = 
точник файл допусти- › 
мого типа и размера. 
Установить данному 
файлу атрибут «только 
для чтения». 
Запустить приложение. 


Дефект: обработанный 
файл появляется в ка- 
талоге-приёмнике, но 
не удаляется из ката- 
лога-источника, файл в 
каталоге-приёмнике 
непрерывно обновля- 
ется (видно по значе- 
нию времени послед- 
него изменения). 








Воспроизводимость 


Срочность 
Важность 


Возможность обойти 





Приложения 


Комментарий 








` Bcerga 


Средняя 








Обычная 





Нет 


Некорректная 
операция 











Если заказчик не планирует |- 
использовать установку ат- 
рибута «только для чтения» 
файлам в каталоге-источ- 
нике для достижения неких 
своих целей, можно просто 
снимать этот атрибут и спо- 
койно перемещать файл. 











Рисунок 2.5.е — Общий вид отчёта о дефекте 





Теперь рассмотрим каждый атрибут подробно. 


Задание 2.5.а: как вы думаете, почему этот отчёт о дефекте можно по 
‚ формальным признакам отклонить с резолюцией «не является дефек- 
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Идентификатор (identifier) представляет собой уникальное значение, позво- 
ляющее однозначно отличить один отчёт о дефекте от другого и используемое во 
всевозможных ссылках. В общем случае идентификатор отчёта о дефекте может 
представлять собой просто уникальный номер, но (если позволяет инструменталь- 
ное средство управления отчётами) может быть и куда сложнее: включать пре- 
фиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро опреде- 
лить суть дефекта и часть приложения (или требований), к которой он относится. 


Краткое описание (summary) должно в предельно лаконичной форме давать 
исчерпывающий ответ на вопросы «Что произошло?» «Где это произошло»? «При 
каких условиях это произошло?». Например: «Отсутствует логотип на странице 
приветствия, если пользователь является администратором»: 

• Что произошло? Отсутствует логотип. 

e Где это произошло? На странице приветствия. 

e При каких условиях это произошло? Если пользователь является админи- 
стратором. 


Одной из самых больших проблем для начинающих тестировщиков является 
именно заполнение поля «краткое описание», которое одновременно должно: 

e содержать предельно краткую, но в то же время достаточную для понимания 
сути проблемы информацию о дефекте; 

e отвечать на только что упомянутые вопросы («что, где и при каких условиях 
случилось») или как минимум на те 1—2 вопроса, которые применимы к кон- 
кретной ситуации; 

• быть достаточно коротким, чтобы полностью помещаться на экране (в тех 
системах управления отчётами о дефектах, где конец этого поля обрезается 
или приводит к появлению скроллинга); 

e при необходимости содержать информацию об окружении, под которым был 
обнаружен дефект; 

e по возможности не дублировать краткие описания других дефектов (и даже 
не быть похожими на них), чтобы дефекты было сложно перепутать или по- 
считать дубликатами друг друга; 

• быть законченным предложением русского или английского (или иного) 
языка, построенным по соответствующим правилам грамматики. 


Для создания хороших кратких описаний дефектов рекомендуется пользо- 
ваться следующим алгоритмом: 

1. Полноценно понять суть проблемы. До тех пор, пока у тестировщика нет чёт- 
кого, кристально чистого понимания того, «что сломалось», писать отчёт о 
дефекте вообще едва ли стоит. 

2. Сформулировать подробное описание (description) дефекта — сначала без 
оглядки на длину получившегося текста. 

3. Убрать из получившегося подробного описания всё лишнее, уточнить важ- 
ные детали. 

4. Выделить в подробном описании слова (словосочетания, фрагменты фраз), 
отвечающие на вопросы, «что, где и при каких условиях случилось». 

5. Оформить получившееся в пункте 4 в виде законченного грамматически пра- 
вильного предложения. 

6. Если предложение получилось слишком длинным, переформулировать его, 
сократив длину (за счёт подбора синонимов, использования общепринятых 
аббревиатур и сокращений). К слову, в английском языке предложение почти 
всегда будет короче русского аналога. 
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Рассмотрим несколько примеров применения этого алгоритма. 
Ситуация 1. Тестированию подвергается некое веб-приложение, поле опи- 


сания товара должно допускать ввод максимум 250 символов; в процессе тестиро- 
вания оказалось, что этого ограничения нет. 


1. 


Суть проблемы: исследование показало, что ни на клиентской, ни на сервер- 
ной части нет никаких механизмов, проверяющих и/или ограничивающих 
длину введённых в поле «О товаре» данных. 

Исходный вариант подробного описания: в клиентской и серверной части 
приложения отсутствуют проверка и ограничение длины данных, вводимых в 
поле «О товаре» на странице http://testapplication/admin/goods/edit/. 
Конечный вариант подробного описания: 

• Фактический результат: в описании товара (поле «О товаре», 
http://testapplication/admin/goods/edit/) отсутствуют проверка и ограни- 
чение длины вводимого текста (МАХ=250 символов). 

e Ожидаемый результат: в случае попытки ввода 251+ символов выво- 
дится сообщение об ошибке. 

Определение «что, где и при каких условиях случилось»: 

• Что: отсутствуют проверка и ограничение длины вводимого текста. 

e Где: описание товара, поле «О товаре», http://testapplication/ad- 
min/goods/edit/. 

• При каких условиях: — (в данном случае дефект присутствует всегда, 
вне зависимости от каких бы то ни было особых условий). 

Первичная формулировка: отсутствуют проверка и ограничение максималь- 
ной длины текста, вводимого в поле «О товаре» описания товара. 
Сокращение (итоговое краткое описание): нет ограничения максимальной 
длины поля «О товаре». Английский вариант: по check for «О товаре» тах 
length. 


Ситуация 2. Попытка открыть в приложении пустой файл приводит к краху 


клиентской части приложения и потере несохранённых пользовательских данных 
на сервере. 


1. 


3. 


4. 


Суть проблемы: клиентская часть приложения начинает «вслепую» читать 
заголовок файла, не проверяя ни размер, ни корректность формата, ничего; 
возникает некая внутренняя ошибка, и клиентская часть приложения некор- 
ректно прекращает работу, не закрыв сессию с сервером; сервер закрывает 
сессию по таймауту (повторный запуск клиентской части запускает новую 
сессию, так что старая сессия и все данные в ней в любом случае утеряны). 
Исходный вариант подробного описания: некорректный анализ открывае- 
мого клиентом файла приводит к краху клиента и необратимой утере теку- 
щей сессии с сервером. 

Конечный вариант подробного описания: 

• Фактический результат: отсутствие проверки корректности открывае- 
мого клиентской частью приложения файла (в том числе пустого) при- 
водит к краху клиентской части и необратимой потере текущей сессии 
с сервером (см. ВК852345). 

• Ожидаемый результат: производится анализ структуры открываемого 
файла; в случае обнаружения проблем отображается сообщение о не- 
возможности открытия файла. 

Определение «что, где и при каких условиях случилось»: 

• Что: крах клиентской части приложения. 

e Где: – (конкретное место в приложении определить едва ли возможно). 

e При каких условиях: при открытии пустого или повреждённого файла. 
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5. 


Первичная формулировка: отсутствие проверки корректности открываемого 
файла приводит к краху клиентской части приложения и потере пользова- 
тельских данных. 

Сокращение (итоговое краткое описание): крах клиента и потеря данных при 
открытии повреждённых файлов. Английский вариант: client crash апа data 
loss оп аатаде/етру files opening. 


Ситуация 3. Крайне редко по совершенно непонятным причинам на сайте 


нарушается отображение всего русского текста (как статических надписей, так и 
данных из базы данных, генерируемых динамически и т.д. — всё «становится во- 
просиками»). 


1. 


Суть проблемы: фреймворк, на котором построен сайт, подгружает специфи- 
ческие шрифты с удалённого сервера; если соединение обрывается, нужные 
шрифты не подгружаются, и используются шрифты по умолчанию, в которых 
нет русских символов. 

Исходный вариант подробного описания: ошибка загрузки шрифтов с удалён- 
ного сервера приводит к использованию локальных несовместимых с требу- 
емой кодировкой шрифтов. 

Конечный вариант подробного описания: 

• Фактический результат: периодическая невозможность загрузить 
шрифты с удалённого сервера приводит к использованию локальных 
шрифтов, несовместимых с требуемой кодировкой. 

• Ожидаемый результат: необходимые шрифты подгружаются всегда 
(или используется локальный источник необходимых шрифтов). 

Определение «что, где и при каких условиях случилось»: 

• Что: используются несовместимые с требуемой кодировкой шрифты. 

e Где: – (по всему сайту). 

e При каких условиях: в случае ошибки соединения с сервером, с KOTO- 
рого подгружаются шрифты. 

Первичная формулировка: периодические сбои внешнего источника шриф- 
тов приводят к сбою отображения русского текста. 

Сокращение (итоговое краткое описание): неверный показ русского текста 
при недоступности внешних шрифтов. Английский вариант: wrong presenta- 
tion of Russian text іп case оѓ external fonts inaccessibility. 


Для закрепления материала ещё раз представим эти три ситуации в виде 


таблицы 2.5.а. 
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Таблица 2.5.а — Проблемные ситуации и формулировки кратких описаний дефек- 


TOB 





Ситуация 


Русский вариант крат- 
кого описания 


Английский вариант 
краткого описания 





Тестированию подвергается некое веб- 
приложение, поле описания товара 
должно допускать ввод максимум 250 
символов; в процессе тестирования ока- 
залось, что этого ограничения нет. 


Нет ограничения макси- 
мальной длины поля «О 
товаре». 


No check for «О товаре» 
max length. 





Попытка открыть в приложении пустой 
файл приводит к краху клиентской части 
приложения и потере несохранённых 
пользовательских данных на сервере. 


Крах клиента и потеря 
данных при открытии по- 
вреждённых/пустых фай- 
лов. 


Client crash and даа loss 
оп damaged/empty files 
opening. 





Крайне редко по совершенно непонят- 
ным причинам на сайте нарушается 
отображение всего русского текста (как 
статических надписей, так и данных из 
базы данных, генерируемых динамиче- 
скии т.д. — всё «становится вопроси- 
ками»). 








Неверный показ русского 
текста при недоступности 
внешних шрифтов. 





Wrong presentation ої 
Russian text in case of 
external fonts inaccessi- 
bility. 








Возвращаемся к рассмотрению полей отчёта о дефекте. 


Подробное описание (description) представляет в развёрнутом виде необ- 
ходимую информацию о дефекте, а также (обязательно!) описание фактического 
результата, ожидаемого результата и ссылку на требование (если это возможно). 


Пример подробного описания: 


Е E Е ЕВ ЕЕ Е Е Е ЕЕ ОЕСР НЧ 


| Если в систему входит администратор, на странице приветствия отсут- 


| ствует логотип. 


| Фактический результат: логотип отсутствует в левом верхнем углу стра- 


| НИЦЫ. 


Ожидаемый результат: логотип отображается в левом верхнем углу стра- 


| НИЦЫ. 
| Требование: К245.3.236. 


В отличие от краткого описания, которое, как правило, является одним пред- 


ложением, здесь можно и нужно давать подробную информацию. Если одна и та 


же проблема (вызванная одним источником) проявляется в нескольких местах при- 
ложения, можно в подробном описании перечислить эти места. 


Шаги по воспроизведению (steps їо reproduce, STR) описывают действия, 


которые необходимо выполнить для воспроизведения дефекта. Это поле похоже 
на шаги тест-кейса, за исключением одного важного отличия: здесь действия про- 
писываются максимально подробно, с указанием конкретных вводимых значений и 
самых мелких деталей, т.к. отсутствие этой информации в сложных случаях может 
привести к невозможности воспроизведения дефекта. 


Пример шагов воспроизведения: 


| 1. Открыть http://testapplication/admin/login/. 
| 2. Авторизоваться с именем «defaultadmin» и паролем «дараѕѕмога». 


| Дефект: в левом верхнем углу страницы отсутствует логотип (вместо 
него отображается пустое пространство с надписью «Іодо»). 


р ИИ анан ин инфо н = и И 1 





Тестирование программного обеспечения. Базовый курс. 


© ЕРАМ Systems, 2015-2021 


Стр: 175/298 


Атрибуты (поля) отчёта о дефекте 





Воспроизводимость (reproducibility) показывает, при каждом ли прохожде- 


нии по шагам воспроизведения дефекта удаётся вызвать его проявление. Это поле 
принимает всего два значения: всегда (always) или иногда (sometimes). 


Можно сказать, что воспроизводимость «иногда» означает, что тестировщик 


не нашёл настоящую причину возникновения дефекта. Это приводит к серьёзным 
дополнительным сложностям в работе с дефектом: 


Тестировщику нужно потратить много времени на то, чтобы удостовериться 
в наличии дефекта (т.к. однократный сбой в работе приложения мог быть вы- 
зван огромным количеством посторонних причин). 

Разработчику тоже нужно потратить время, чтобы добиться проявления де- 
фекта и убедиться в его наличии. После внесения исправлений в приложение 
разработчик фактически должен полагаться только на свой профессиона- 
лизм, т.к. даже многократное прохождение по шагам воспроизведения в та- 
ком случае не гарантирует, что дефект был исправлен (возможно, через ещё 
10—20 повторений он бы проявился). 

Тестировщику, верифицирующему исправление дефекта и вовсе остаётся 
верить разработчику на слово по той же самой причине: даже если он попы- 
тается воспроизвести дефект 100 раз и потом прекратит попытки, может так 
случиться, что на 101-й раз дефект всё же воспроизвёлся бы. 


Как легко догадаться, такая ситуация является крайне неприятной, а потому 


рекомендуется один раз потратить время на тщательную диагностику проблемы, 
найти её причину и перевести дефект в разряд воспроизводимых всегда. 


Важность (severity) показывает степень ущерба, который наносится проекту 


существованием дефекта. 


В общем случае выделяют следующие градации важности: 

Критическая (critical) — существование дефекта приводит к масштабным NO- 
следствиям катастрофического характера, например: потеря данных, рас- 
крытие конфиденциальной информации, нарушение ключевой функциональ- 
ности приложения и т.д. 

Высокая (тајог) — существование дефекта приносит ощутимые неудобства 
многим пользователям в рамках их типичной деятельности, например: недо- 
ступность вставки из буфера обмена, неработоспособность общепринятых 
клавиатурных комбинаций, необходимость перезапуска приложения при вы- 
полнении типичных сценариев работы. 

Средняя (medium) — существование дефекта слабо влияет на типичные CUE- 
нарии работы пользователей, и/или существует обходной путь достижения 
цели, например: диалоговое окно не закрывается автоматически после нажа- 
тия кнопок «ОК»/«Сапсе!», при распечатке нескольких документов подряд не 
сохраняется значение поля «Двусторонняя печать», перепутаны направле- 
ния сортировок по некоему полю таблицы. 

Низкая (ттог) — существование дефекта редко обнаруживается незначи- 
тельным процентом пользователей и (почти) не влияет на их работу, напри- 
мер: опечатка в глубоко вложенном пункте меню настроек, некое окно сразу 
при отображении расположено неудобно (нужно перетянуть его в удобное 
место), неточно отображается время до завершения операции копирования 
файлов. 
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Срочность (priority) показывает, как быстро дефект должен быть устранён. 
В общем случае выделяют следующие градации срочности: 

e Наивысшая (ASAP, as soon as possible) срочность указывает на необходи- 
мость устранить дефект настолько быстро, насколько это возможно. B зави- 
симости от контекста «настолько быстро, насколько возможно» может варь- 
ироваться от «в ближайшем билде» до единиц минут. 

e Высокая (high) срочность означает, что дефект следует исправить вне оче- 
реди, т.к. его существование или уже объективно мешает работе, или начнёт 
создавать такие помехи в самом ближайшем будущем. 

• Обычная (погта!) срочность означает, что дефект следует исправить в по- 
рядке общей очерёдности. Такое значение срочности получает большинство 
дефектов. 

e Низкая (low) срочность означает, что в обозримом будущем исправление 
данного дефекта не окажет существенного влияния на повышение качества 
продукта. 


Несколько дополнительных рассуждений о важности и срочности стоит 
рассмотреть отдельно. 

Один из самых частых вопросов относится к тому, какая между ними связь. 
Никакой. Для лучшего понимания этого факта можно сравнить важность и сроч- 
ность с координатами Х и Ү точки на плоскости. Хоть «на бытовом уровне» и ка- 
жется, что дефект с высокой важностью следует исправить в первую очередь, в 
реальности ситуация может выглядеть совсем иначе. 

Чтобы проиллюстрировать эту мысль подробнее, вернёмся к перечню града- 
ций: заметили ли вы, что для разных степеней важности примеры приведены, а для 
разных степеней срочности — нет? И это не случайно. 

Зная суть проекта и суть дефекта, его важность определить достаточно 
легко, т.к. мы можем проследить влияние дефекта на критерии качества, степень 
выполнения требований той или иной важности и т.д. Но срочность исправления 
дефекта можно определить только в конкретной ситуации. 

Поясним на жизненном примере: насколько для жизни человека важна вода? 
Очень важна, без воды человек умирает. Значит, важность воды для человека 
можно оценить как критическую. Но можем ли мы ответить на вопрос «Как быстро 
человеку нужно выпить воды?», не зная, о какой ситуации идёт речь? Если рассмат- 
риваемый человек умирает от жажды в пустыне, срочность будет наивысшей. Если 
он просто сидит в офисе и думает, не попить ли чая, срочность будет обычной или 
даже низкой. 

Вернёмся к примерам из разработки программного обеспечения и покажем 
четыре случая сочетания важности и срочности в таблице 2.5.5. 


Таблица 2.5.6 — Примеры сочетания важности и срочности дефектов 





Важность (Severity) 
Критическая (Critical) Низкая (Мтог) 
Проблемы с безопасностью | На корпоративном сайте повре- 
во введённом в эксплуата- | дилась картинка с фирменным 








Наивысшая 




















(АЗАР) цию банковском ПО. логотипом. 
Срочность В самом начале разработки | В руководстве пользователя об- 
(Priority) проекта обнаружена ситуа- | наружено несколько опечаток, 
Низкая ция, при которой могут быть | не влияющих на смысл текста. 
(Low) повреждены или вовсе уте- 
ряны пользовательские дан- 
ные. 
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Симптом (symptom) — позволяет классифицировать дефекты по их типич- 


ному проявлению. Не существует никакого общепринятого списка симптомов. Бо- 
лее того, далеко не в каждом инструментальном средстве управления отчётами о 
дефектах есть такое поле, а там, где оно есть, его можно настроить. В качестве 
примера рассмотрим следующие значения симптомов дефекта. 


Косметический дефект (cosmetic flaw) — визуально заметный недостаток NH- 
терфейса, не влияющий на функциональность приложения (например, 
надпись на кнопке выполнена шрифтом не той гарнитуры). 
Повреждение/потеря данных (data corruption/loss) — в результате возникно- 
вения дефекта искажаются, уничтожаются (или не сохраняются) некоторые 
данные (например, при копировании файлов копии оказываются повреждён- 
ными). 

Проблема в документации (documentation issue) — дефект относится не к 
приложению, а к документации (например, отсутствует раздел руководства 
по эксплуатации). 

Некорректная операция (incorrect operation) — некоторая операция выполня- 
ется некорректно (например, калькулятор показывает ответ 17 при умноже- 
нии 2 на 3). 

Проблема инсталляции (installation problem) — дефект проявляется на ста- 
дии установки и/или конфигурирования приложения (см. инсталляционное 
тестирование з). 

Ошибка локализации (localization issue) — что-то в приложении не переве- 
дено или переведено неверно на выбранный язык интерфейса (см. локали- 
зационное тестирование°)). 

Нереализованная функциональность (missing feature) — некая функция npn- 
ложения не выполняется или не может быть вызвана (например, в списке 
форматов для экспорта документа отсутствует несколько пунктов, которые 
там должны быть). 

Проблема масштабируемости (scalability) — при увеличении количества до- 
ступных приложению ресурсов не происходит ожидаемого прироста произво- 
дительности приложения (см. тестирование производительности?? и тести- 
рование масштабируемости). 

Низкая производительность (low performance) — выполнение неких операций 
занимает недопустимо большое время (см. тестирование производительно- 
сти®®}), 

Крах системы (system crash) — приложение прекращает работу или теряет 
способность выполнять свои ключевые функции (также может сопровож- 
даться крахом операционной системы, веб-сервера и т.д.). 

Неожиданное поведение (unexpected behavior) — в процессе выполнения HE- 
которой типичной операции приложение ведёт себя необычным (отличным 
от общепринятого) образом (например, после добавления в список новой за- 
писи активной становится не новая запись, а первая в списке). 
Недружественное поведение (unfriendly behavior) — поведение приложения 
создаёт пользователю неудобства в работе (например, на разных диалого- 
вых окнах в разном порядке расположены кнопки «ОК» и «Сапсе!»). 
Расхождение с требованиями (variance from specs) — этот симптом указы- 
вают, если дефект сложно соотнести с другими симптомами, но тем не менее 
приложение ведёт себя не так, как описано в требованиях. 

Предложение по улучшению (enhancement) — во многих инструментальных 
средствах управления отчётами о дефектах для этого случая есть отдельный 
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вид отчёта, т.к. предложение по улучшению формально нельзя считать де- 
фектом: приложение ведёт себя согласно требованиям, но у тестировщика 
есть обоснованное мнение о том, как ту или иную функциональность можно 
улучшить. 


Часто встречается вопрос о том, может ли у одного дефекта быть сразу не- 
сколько симптомов. Да, может. Например, крах системы очень часто ведёт к потере 
или повреждению данных. Но в большинстве инструментальных средств управле- 
ния отчётами о дефектах значение поля «Симптом» выбирается из списка, и потому 
нет возможности указать два и более симптома одного дефекта. В такой ситуации 
рекомендуется выбирать либо симптом, который лучше всего описывает суть ситу- 
ации, либо «наиболее опасный» симптом (например, недружественное поведение, 
состоящее в том, что приложение не запрашивает подтверждения перезаписи су- 
ществующего файла, приводит к потере данных; здесь «потеря данных» куда 
уместнее, чем «недружественное поведение»). 


Возможность обойти (workaround) — показывает, существует ли альтерна- 
тивная последовательность действий, выполнение которой позволило бы пользо- 
вателю достичь поставленной цели (например, клавиатурная комбинация Ctrl+P не 
работает, но распечатать документ можно, выбрав соответствующие пункты в 
меню). В некоторых инструментальных средствах управления отчётами о дефектах 
это поле может просто принимать значения «Да» и «Нет», в некоторых при выборе 
«Да» появляется возможность описать обходной путь. Традиционно считается, что 
дефектам без возможности обхода стоит повысить срочность исправления. 


Комментарий (comments, additional info) — может содержать любые полез- 
ные для понимания и исправления дефекта данные. Иными словами, сюда можно 
писать всё то, что нельзя писать в остальные поля. 


Вложения (attachments) — представляет собой не столько поле, сколько CNN- 
сок прикреплённых к отчёту о дефекте приложений (копий экрана, вызывающих 
сбой файлов и т.д.). 

Общие рекомендации по формированию приложений таковы: 

e Если вы сомневаетесь, делать или не делать приложение, лучше сделайте. 

e Обязательно прилагайте т.н. «проблемные артефакты» (например, файлы, 
которые приложение обрабатывает некорректно). 

e Если вы прилагаете копию экрана: 

о Чаще всего вам будет нужна копия активного окна (АЇї+Ргіпі$сгееп), а 
не всего экрана (PrintScreen). 

о Обрежьте всё лишнее (используйте Snipping Tool или Paint в Windows, 
Pinta или ХРаіпі в Linux). 

о Отметьте на копии экрана проблемные места (обведите, нарисуйте 
стрелку, добавьте надпись — сделайте всё необходимое, чтобы с пер- 
вого взгляда проблема была заметна и понятна). 

о В некоторых случаях стоит сделать одно большое изображение из не- 
скольких копий экрана (разместив их последовательно), чтобы пока- 
зать процесс воспроизведения дефекта. Альтернативой этого реше- 
ния является создание нескольких копий экрана, названных так, чтобы 
имена образовывали последовательность, например: 6г_9_$с_01.рпд, 
бг 9 ѕс 02.рпд, бг 9 ѕс 03.рпд. 

о Сохраните копию экрана в формате JPG (если важна экономия объёма 
данных) или РМС (если важна точная передача картинки без искаже- 
НИЙ). 
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» Если вы прилагаете видеоролик с записью происходящего на экране, обяза- 
тельно оставляйте только тот фрагмент, который относится к описываемому 
дефекту (это будет буквально несколько секунд или минут из возможных 
многих часов записи). Старайтесь подобрать настройки кодеков так, чтобы 
получить минимальный размер ролика при сохранении достаточного каче- 
ства изображения. 

• Поэкспериментируйте с различными инструментами создания копий экрана 
и записи видеороликов с происходящим на экране. Выберите наиболее удоб- 
ное для вас программное обеспечение и приучите себя постоянно его ис- 
пользовать. 


Для более глубокого понимания принципов оформления отчётов о дефектах 
рекомендуется прямо сейчас ознакомиться с главой «Типичные ошибки при напи- 
сании отчётов о дефектах» "9. 
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2.5.4. Инструментальные средства управления отчётами о дефек- 
тах 





‚ Так называемые «инструментальные средства управления отчётами о де- 


| ® ‚ фектах» в обычной разговорной речи называют «баг-трекинговыми систе- | 
_ мами», «баг-трекерами» и т.д. Но мы здесь по традиции будем придержи- . 





Инструментальных средств управления отчётами о дефектах (bug tracking 
system, defect management {00!'7) очень много", к тому же многие компании paspa- 
батывают свои внутренние средства решения этой задачи. Зачастую такие инстру- 
ментальные средства являются частями инструментальных средств управления 
тестированием! 7. 

Как и в случае с инструментальными средствами управления тестированием, 
здесь не имеет смысла заучивать, как работать с отчётами о дефектах в том или 
ином средстве. Мы лишь рассмотрим общий набор функций, как правило, реализу- 
емых такими средствами: 

• Создание отчётов о дефектах, управление их жизненным циклом с учётом 
контроля версий, прав доступа и разрешённых переходов из состояния в со- 
стояние. 

e Сбор, анализ и предоставление статистики в удобной для восприятия Yeno- 
веком форме. 

• Рассылка уведомлений, напоминаний и иных артефактов соответствующим 
сотрудникам. 

e Организация взаимосвязей между отчётами о дефектах, тест-кейсами, тре- 
бованиями и анализ таких связей с возможностью формирования рекомен- 
даций. 

• Подготовка информации для включения в отчёт о результатах тестирования. 

e Интеграция с системами управления проектами. 


Иными словами, хорошее инструментальное средство управления жизнен- 
ным циклом отчётов о дефектах не только избавляет человека от необходимости 
внимательно выполнять большое количество рутинных операций, но и предостав- 
ляет дополнительные возможности, облегчающие работу тестировщика и делаю- 
щие её более эффективной. 


Для общего развития и лучшего закрепления темы об оформлении отчётов 
о дефектах мы сейчас рассмотрим несколько картинок с формами из разных ин- 
струментальных средств. 

Здесь вполне сознательно не приведено никакого сравнения или подробного 
описания — подобных обзоров достаточно в Интернете, и они стремительно уста- 
ревают по мере выхода новых версий обозреваемых продуктов. 

Но интерес представляют отдельные особенности интерфейса, на которые 
мы обратим внимание в каждом из примеров (важно: если вас интересует подроб- 
ное описание каждого поля, связанных с ним процессов и т.д., обратитесь к офици- 
альной документации — здесь будут лишь самые краткие пояснения). 





317 Defect management tool, Incident management tool. А tool that facilitates the recording and status tracking ої defects апа 
changes. They often have workflow-oriented facilities to track and control the allocation, correction and re-testing of defects and 
provide reporting facilities. See also incident management tool. [ISTQB Glossary] 

318 «Comparison of issue-tracking systems», Wikipedia [http://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems] 
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—_ 


8. 


9. 


Jira?! 


Project (проект) позволяет указать, к какому проекту относится дефект. 

Issue type (тип записи/артефакта) позволяет указать, что именно представ- 
ляет собой создаваемый артефакт. JIRA позволяет создавать не только OT- 
чёты о дефектах, но и множество других артефактовз20, типы которых можно 
настраивать". По умолчанию представлены: 

e Improvement (предложение по улучшению) — было описано подробно 
в разделе, посвящённом полям отчёта о дефекте (см. описание поля 
«симптом», значение «предложение по улучшению»). 

e New feature (новая особенность) — описание новой функционально- 
сти, нового свойства, новой особенности продукта. 

e Task (задание) — некое задание для выполнения тем или иным участ- 
ником проектной команды. 

e Custom issue (произвольный артефакт) — как правило, это значение 
при настройке JIRA удаляют, заменяя своими вариантами, или nepe- 
именовывают в Issue. 

Ѕиттагу (краткое описание) позволяет указать краткое описание дефекта. 
Priority (срочность) позволяет указать срочность исправления дефекта. По 
умолчанию JIRA предлагает следующие варианты: 

Highest (самая высокая срочность). 

High (высокая срочность). 

Medium (обычная срочность). 

Low (низкая срочность). 

e Lowest (самая низкая срочность). 

Обратите внимание: по умолчанию поля severity (важность) нет. Но его 
можно добавить. 

Components (компоненты) содержит перечень компонентов приложения, за- 
тронутых дефектом (хотя иногда здесь перечисляют симптомы дефектов). 
Affected versions (затронутые версии) содержит перечень версий продукта, в 
которых проявляется дефект. 

Environment (окружение) содержит описание аппаратной и программной KOH- 
фигурации, в которой проявляется дефект. 

Description (подробное описание) позволяет указать подробное описание де- 
фекта. 

Original estimate (начальная оценка времени исправления) позволяет указать 
начальную оценку того, сколько времени займёт устранение дефекта. 


10. Remaining estimate (расчётное остаточное время исправления) показывает, 


сколько времени осталось от начальной оценки. 


11. югу points (оценочные единицы) позволяет указать сложность дефекта (или 


ИНОГО артефакта) в специальных оценочных единицах, принятых в гибких ме- 
тодологиях управления проектами. 


12.1 абе!$ (метки) содержит метки (теги, ключевые слова), по которым можно 


группировать и классифицировать дефекты и иные артефакты. 


13.Еріс/Тһете (история/область) содержит перечень высокоуровневых меток, 


описывающих относящиеся к дефекту крупные области требований, крупные 
модули приложения, крупные части предметной области, объёмные пользо- 
вательские истории и т.д. 





319 «JIRA — Issue & Project Tracking Software» [https://www.atlassian.com/software/jira/] 
320 «What is an Issue» [https://confluence.atlassian.com/jira063/what-is-an-issue-683542485.html] 
321 «Defining Issue Type Field Values» [https://confluence.atlassian.com/display/JIRA/Defining+Issue+Type+Field+Values] 
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Create Issue $È Configure Fields ~ | 
Project ” 
Issue Туре’ (е) Вид - © 
Summary* 
^ Major - о 
Component/s x 
Start typing to get a list of possible matches or press down to select. 


Affects Version/s 


Start typing to get a list of possible matches or press down to select. 
Environment 


Рог exanple operating sy stem, software platform and/or hardware specifications (include as appropriate for 
the issue). 


Description 


Бо 
Original Estimate (eg. 3w 4d 12h) © 





The original estimate of how much work is involved in гезомтд this issue 


Remaining Estimate (ед. Зм 4d 12h) © 
An estimate of how much work remains until this issue will be resolved. 
Story Points 
Measurement of complexity and/or sze of a requirement. 
Labels z 
Begin typing to find and create labels or press down to select a suggested label 


Epic/Theme м 


Begin typing їо find and create labels or press down to select а suggested label. 


Field that will help you regroup issues under an Epic or under a theme. 


External issue ID 


External issue ID A15) 
Epic Link = 
Choose ап еріс їо assign this issue to 
Has a Story/s 26) 


Link/sto Story issue type 


Tester A 


Start typing to get a list of possible matches. 


Additional 
information 


Sprint None 
JIRA Agile sprint field 


E create another Cancel 


Рисунок 2.5.f — Создание отчёта о дефекте B JIRA 
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14. External issue іа (идентификатор внешнего артефакта) позволяет связать OT- 
чёт о дефекте или иной артефакт с внешним документом. 

15. Epic link (ссылка на историю/область) содержит ссылку на историю/область 
(см. пункт 13), наиболее близко относящуюся к дефекту. 

16.Наѕ а ѕіогу/ѕ (истории) содержит ссылки и/или описание пользовательских 
историй, связанных с дефектом (как правило, здесь приводятся ссылки на 
внешние документы). 

17. Tester (тестировщик) содержит имя автора описания дефекта. 

18. Additional information (дополнительная информация) содержит полезную до- 
полнительную информацию о дефекте. 

19. Sprint (спринт) содержит номер спринта (2—4-недельной итерации разработки 
проекта в терминологии гибких методологий управления проектами), во 
время которого был обнаружен дефект. 


Многие дополнительные поля и возможности становятся доступными при 
других операциях с дефектами (просмотром или редактированием созданного де- 
фекта, просмотре отчётов и т.д.). 


Bugzilla??? 


1. Product (продукт) позволяет указать, к какому продукту (проекту) относится 
дефект. 

2. Reporter (автор отчёта) содержит e-mail автора описания дефекта. 

З. Component (компонент) содержит указание компонента приложения, к KOTO- 
рому относится описываемый дефект. 

4. Component description (описание компонента) содержит описание компо- 
нента приложения, к которому относится описываемый дефект. Эта инфор- 
мация загружается автоматически при выборе компонента. 

5. Мегѕіоп (версия) содержит указание версии продукта, в которой был обнару- 
жен дефект. 

6. Severity (важность) содержит указание важности дефекта. По умолчанию 
предложены такие варианты: 

e Blocker (блокирующий дефект) — дефект не позволяет решить с NOMO- 
щью приложения некоторую задачу. 

Сийса! (критическая важность). 

Ма]ог (высокая важность). 

Normal (обычная важность). 

Minor (низкая важность). 

Тима! (самая низкая важность). 

Enhancement (предложение по улучшению) — было описано подробно 

в разделе, посвящённом полям отчёта о дефекте (см. описание поля 

«симптом», значение «предложение по улучшению» `7). 

7. Нагамаге (аппаратное обеспечение) позволяет выбрать профиль аппарат- 
ного окружения, в котором проявляется дефект. 

8. OS (операционная система) позволяет указать операционную систему, под 
которой проявляется дефект. 





322 «Bugzilla» [https://www.bugzilla.org] 
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* Product: TestProduct 2. Reporter: иѕег@иѕег.сот L2) 


* Component: итш ~ Component Description 
This is a test component. 


| L 


* version: ШЙ ~ Severity: enhancement = Q 
Hardware: P 
05: Windows ~ = © 











Status: CONFIRMED v 
Assignee: adm@adm.com 


сс: 
Default СС: 
Orig. Est.: 


Deadline: 





Alias: 


URL: http:// 





* Summary: | 


Description: 











Attachment: | дад an attachment Ө) 
Depends оп: 


Blocks: 


| Submit Bug | | Remember values аз БооктагкаЫе template 


Рисунок 2.5.9 — Создание отчёта о дефекте в Bugzilla 


9. Priority (срочность) позволяет указать срочность исправления дефекта. По 
умолчанию Bugzilla предлагает следующие варианты: 

Highest (самая высокая срочность). 

High (высокая срочность). 

Normal (обычная срочность). 

Low (низкая срочность). 

Lowest (самая низкая срочность). 
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10. Status (статус) позволяет установить статус отчёта о дефекте. По умолчанию 

Bugzilla предлагает следующие варианты статусов: 
e Unconfirmed (не подтверждено) — дефект пока не изучен, и нет гаран- 
тии того, что он действительно корректно описан. 
e Confirmed (подтверждено) — дефект изучен, корректность описания 
подтверждена. 
e Іп progress (в работе) — ведётся работа по изучению и устранению де- 
фекта. 
В официальной документации рекомендуется сразу же после установки 
Bugzilla сконфигурировать набор статусов и правила жизненного цикла OT- 
чёта о дефектах в соответствии с принятыми в вашей компании правилами. 
11.Аѕѕідпее (ответственный) указывает e-mail участника проектной команды, OT- 
ветственного за изучение и исправление дефекта. 

12.СС (уведомлять) содержит список e-mail адресов участников проектной KO- 
манды, которые будут получать уведомления о происходящем с данным де- 
фектом. 

13. Default СС (уведомлять по умолчанию) содержит e-mail адрес(а) участников 
проектной команды, которые по умолчанию будут получать уведомления о 
происходящем с любыми дефектами (чаще всего здесь указываются е-тай 
адреса рассылок). 

14.Опдта! estimation (начальная оценка) позволяет указать начальную оценку 
того, сколько времени займёт устранение дефекта. 

15.реааііпе (крайний срок) позволяет указать дату, к которой дефект обяза- 
тельно нужно исправить. 

16. Alias (псевдоним) позволяет указать короткое запоминающееся название де- 
фекта (возможно, в виде некоей аббревиатуры) для удобства упоминания 
дефекта в разнообразных документах. 

17. ЦВЕ (URL) позволяет указать URL, по которому проявляется дефект (осо- 
бенно актуально для веб-приложений). 

18. Summary (краткое описание) позволяет указать краткое описание дефекта. 

19. Description (подробное описание) позволяет указать подробное описание де- 
фекта. 

20. Attachment (вложение) позволяет добавить к отчёту о дефекте вложения в 
виде прикреплённых файлов. 

21.Оерепа$ оп (зависит от) позволяет указать перечень дефектов, которые 
должны быть устранены до начала работы с данным дефектом. 

22.Віоскѕ (блокирует) позволяет указать перечень дефектов, к работе с KOTO- 
рыми можно будет приступить только после устранения данного дефекта. 
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Mantis?» 


Enter Report Details 

*Category [All Projects] General ~ 

Reproducibility have not tried X 

Severity minor ~ Ө) 
Priority normal v m ‹ ) 

Select Profile Or Fill In 

Platform в м 

os ®@- 

OS Version (в) 

Product Version ы 


*Ѕиттагу 





*Description 
Steps To Reproduce 


Additional Information 


о 
A 
29 

JO 


Upload File | Вгомзе.. | № file selected. 
Maximum size: 2,097 КВ 


View Status ® public private О 
Report Stay check to report more issues 


| Submit Report | 


Ә 








* required 





Рисунок 2.5.h — Создание отчёта о дефекте в Mantis 


1. Category (категория) содержит указание проекта или компонента приложе- 
ния, к которому относится описываемый дефект. 
2. Reproducibility (воспроизводимость) дефекта. Mantis предлагает нетипично 
большое количество вариантов: 
e Always (всегда). 
e Sometimes (иногда). 
e Random (случайным образом) — вариация Ha тему «иногда», когда He 
удалось установить никакой закономерности проявления дефекта. 
e Have пої tried (не проверено) — это не столько воспроизводимость, 
сколько статус, но Mantis относит это значение к данному полю. 





323 «Mantis Вид Tracker» [https://www.mantisbt.org] 
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3. 


8. 


9. 


e Unable to reproduce (не удалось воспроизвести) — это не столько BOC- 
производимость, сколько резолюция к отклонению отчёта о дефекте, 
но в Mantis тоже отнесено к данному полю. 

e М/А (non-applicable, неприменимо) — используется для дефектов, к KO- 
торым не применимо понятие воспроизводимости (например, про- 
блемы с документацией). 

Severity (важность) содержит указание важности дефекта. По умолчанию 
предложены такие варианты: 

e Block (блокирующий дефект) — дефект не позволяет решить с NOMO- 
щью приложения некоторую задачу. 

e Crash (критическая важность) — как правило, относится к дефектам, 

вызывающим неработоспособность приложения. 

Ма]ог (высокая важность). 

Minor (низкая важность). 

Тмеак (доработка) — как правило, косметический дефект. 

Text (текст) — как правило, дефект относится к тексту (опечатки и т.д.). 
Тима! (самая низкая важность). 

Feature (особенность) — отчёт представляет собой не описание де- 
фекта, а запрос на добавление/изменение функциональности или 
свойств приложения. 

Priority (срочность) позволяет указать срочность исправления дефекта. По 
умолчанию Mantis предлагает следующие варианты: 

e Immediate (незамедлительно). 

Urgent (самая высокая срочность). 
High (высокая срочность). 

Normal (обычная срочность). 

Low (низкая срочность). 

e None (нет) — срочность не указана или не может быть определена. 
Select profile (выбрать профиль) позволяет выбрать из заранее подготовлен- 
ного списка профиль аппаратно-программной конфигурации, под которой 
проявляется дефект. Если такого списка нет или он не содержит необходи- 
мых вариантов, можно вручную заполнить поля 6-7-8 (см. ниже). 

Platform (платформа) позволяет указать аппаратную платформу, под которой 
проявляется дефект. 

OS (операционная система) позволяет указать операционную систему, под 
которой проявляется дефект. 

OS Version (версия операционной системы) позволяет указать версию one- 
рационной системы, под которой проявляется дефект. 

Product version (версия продукта) позволяет указать версию приложения, в 
которой был обнаружен дефект. 


10. Summary (краткое описание) позволяет указать краткое описание дефекта. 
11. Description (подробное описание) позволяет указать подробное описание де- 


фекта. 


12. Steps to reproduce (шаги по воспроизведению) позволяет указать шаги по BOC- 


произведению дефекта. 


13. Additional information (дополнительная информация) позволяет указать лю- 


бую дополнительную информацию, которая может пригодиться при анализе 
и устранении дефекта. 


14. Upload file (загрузить файл) позволяет загрузить копии экрана и тому подоб- 


ные файлы, которые могут быть полезны при анализе и устранении дефекта. 
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15. View status (статус просмотра) позволяет управлять правами доступа к OT- 
чёту о дефекте и предлагает по умолчанию два варианта: 
e Public (публичный). 
e Private (закрытый). 
16. Report stay (остаться в режиме добавления отчётов) — отметка этого поля 
позволяет после сохранения данного отчёта сразу же начать писать следую- 
щий. 






адание 2.5.6: изучите ещё 3—5 инструментальных средств управления 


| АЕ | жизненным циклом отчётов о дефектах, почитайте документацию по ним, 
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2.5.5. Свойства качественных отчётов о дефектах 


Отчёт о дефекте может оказаться некачественным (а следовательно, веро- 


ятность исправления дефекта понизится), если в нём нарушено одно из следующих 
СВОЙСТВ. 


Тщательное заполнение всех полей точной и корректной информацией. 


Нарушение этого свойства происходит по множеству причин: недостаточный опыт 
тестировщика, невнимательность, лень и т.д. Самыми яркими проявлениями такой 
проблемы можно считать следующие: 


Часть важных для понимания проблемы полей не заполнена. В результате 
отчёт превращается в набор обрывочных сведений, использовать которые 
для исправления дефекта невозможно. 

Предоставленной информации недостаточно для понимания сути проблемы. 
Например, из такого плохого подробного описания вообще не ясно, о чём 
идёт речь: «Приложение иногда неверно конвертирует некоторые файлы». 
Предоставленная информация является некорректной (например, указаны 
неверные сообщения приложения, неверные технические термины и т.д.). 
Чаще всего такое происходит по невнимательности (последствия ошибоч- 
ного copy-paste и отсутствия финальной вычитки отчёта перед публикацией). 
«Дефект» (именно так, в кавычках) найден в функциональности, которая ещё 
не была объявлена как готовая к тестированию. То есть тестировщик конста- 
тирует, что неверно работает то, что и не должно было (пока!) верно рабо- 
тать. 

В отчёте присутствует жаргонная лексика: как в прямом смысле — нелитера- 
турные высказывания, таки некие технические жаргонизмы, понятные крайне 
ограниченному кругу людей. Например: «Фигово подцепились чартники». 
(Имелось в виду: «Не все таблицы кодировок загружены успешно».) 

Отчёт вместо описания проблемы с приложением критикует работу кого-то 
из участников проектной команды. Например: «Ну каким дураком надо быть, 
чтобы такое сделать?!» 

В отчёте упущена некая незначительная на первый взгляд, но по факту кри- 
тичная для воспроизведения дефекта проблема. Чаще всего это проявля- 
ется в виде пропуска какого-то шага по воспроизведению, отсутствию или не- 
достаточной подробности описания окружения, чрезмерно обобщённом ука- 
зании вводимых значений и т.п. 

Отчёту выставлены неверные (как правило, заниженные) важность или сроч- 
ность. Чтобы избежать этой проблемы, стоит тщательно исследовать де- 
фект, определять его наиболее опасные последствия и аргументированно 
отстаивать свою точку зрения, если коллеги считают иначе. 

К отчёту не приложены необходимые копии экрана (особенно важные для 
косметических дефектов) или иные файлы. Классика такой ошибки: отчёт 
описывает неверную работу приложения с некоторым файлом, но сам файл 
не приложен. 

Отчёт написан безграмотно с точки зрения человеческого языка. Иногда на 
это можно закрыть глаза, но иногда это становится реальной проблемой, 
например: «Not keyboard т parameters accepting values» (это реальная yn- 
тата; и сам автор так и не смог пояснить, что же имелось в виду). 
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Правильный технический язык. Это свойство в равной мере относится и к 
требованиям, и к тест-кейсам, и к отчётам о дефектах — к любой документации, а 
потому не будем повторяться — см. описанное ранее! 3}, 


Сравните два подробных описания дефекта: 





Плохое подробное описание Хорошее подробное описание 
Когда мы как будто бы хотим убрать папку, где | Не производится запрос подтверждения при 
что-то внутри есть, оно не спрашивает, хотим | удалении непустого подкаталога в каталоге 
ли мы. ЗОЧАСЕ РІА. 
Act: производится удаление непустого подката- 
лога (со всем его содержимым) в каталоге 
SOURCE_DIR без запроса подтверждения. 
Exp: в случае, если в каталоге SOURCE_DIR 
приложение обнаруживает непустой подката- 
лог, оно прекращает работу с выводом сообще- 
ния «Моп-етру subfolder [имя подкаталога] т 
ЗОЧВАСЕ_ РІВ folder detected. Remove it manu- 
ally or restart application with --force_file_opera- 
tions key to remove automatically.» 
Req: UR.56.BF.4.c. 

















Специфичность описания шагов. Говоря о тест-кейсах, мы подчёркивали, 
что в их шагах стоит придерживаться золотой середины между специфичностью и 
общностью. В отчётах о дефектах предпочтение, как правило, отдаётся специфич- 
ности по очень простой причине: нехватка какой-то мелкой детали может привести 
к невозможности воспроизведения дефекта. Потому, если у вас есть хоть малей- 
шее сомнение в том, важна ли какая-то деталь, считайте, что она важна. 
Сравните два набора шагов по воспроизведению дефекта: 








Недостаточно специфичные шаги Достаточно специфичные шаги 
1. Отправить на конвертацию файл допусти- | 1. Отправить на конвертацию файл в формате 
мого формата и размера, в котором русский HTML размером от 100 КБ до 1 МБ, в KOTO- 
текст представлен в разных кодировках. ром русский текст представлен в кодировках 


UTF8 (10 строк по 100 символов) и WIN-1251 


Дефект: конвертация кодировок произво- (20 строк по 100 символов). 


дится неверно. 
Дефект: текст, который был представлен в 
ИТЕ8, повреждён (представлен нечитаемым 
набором символов). 














В первом случае воспроизвести дефект практически нереально, т.к. он за- 
ключается в особенностях работы внешних библиотек по определению кодировок 
текста в документе, в то время как во втором случае данных достаточно если и не 
для понимания сути происходящего (дефект на самом деле очень «хитрый»), то 
хотя бы для гарантированного воспроизведения и признания факта его наличия. 

Ещё раз главная мысль: в отличие от тест-кейса отчёт о дефекте может об- 
ладать повышенной специфичностью, и это будет меньшей проблемой, чем невоз- 
можность воспроизведения дефекта из-за излишне обобщённого описания про- 
блемы. 
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Отсутствие лишних действий и/или их длинных описаний. Чаще всего 
это свойство подразумевает, что не нужно в шагах по воспроизведению дефекта 


долго и по пунктам расписывать то, что можно заменить одной фразой: 





Плохо 


Хорошо 





1. Указать в качестве первого параметра при- 
ложения путь к папке с исходными файлами. 
2. Указать в качестве второго параметра при- 
ложения путь к папке с конечными файлами. 
3. Указать в качестве третьего параметра при- 


1. Запустить приложение со всеми тремя кор- 
ректными параметрами (особенно обратить 
внимание, чтобы SOURCE_DIR и DESTINA- 
ТІОМ ВІА не совпадали и не были вложены 
друг в друга в любом сочетании). 


ложения путь к файлу журнала. 


4. Запустить приложение. Дефект: приложение прекращает работу с 


сообщением «SOURCE_DIR апа DESTINA- 
ТОМ ВІВ тау пої be ће same!» (судя по 
всему, первый параметр командной строки 
используется для инициализации имён 
обоих каталогов.) 


Дефект: приложение использует первый па- 
раметр командной строки и как путь к папке 
с исходными файлами, и как путь к папке с 
конечными файлами. 














Вторая по частоте ошибка — начало каждого отчёта о дефекте с запуска при- 
ложения и подробного описания по приведению его в то или иное состояние. 
Вполне допустимой практикой является написание в отчёте о дефекте приготовле- 
ний (по аналогии с тест-кейсами) или описание нужного состояния приложения в 
одном (первом) шаге. 








Сравните: 
Плохо Хорошо 
1. Запустить приложение со всеми верными | Предусловие: приложение запущено и прора- 
параметрами. ботало более 30 минут. 
2. Подождать более 30 минут. 1. Передать на конвертацию файл допусти- 


мого формата и размера. 


Дефект: 


файл. 


3. Передать на конвертацию файл допусти- 
мого формата и размера. 


Дефект: 


файл. 


приложение не обрабатывает 


приложение не обрабатывает 














Отсутствие дубликатов. Когда в проектной команде работает большое ко- 
личество тестировщиков, может возникнуть ситуация, при которой один и тот же 
дефект будет описан несколько раз разными людьми. А иногда бывает так, что 
даже один и тот же тестировщик уже забыл, что когда-то давно уже обнаруживал 
некую проблему, и теперь описывает её заново. Избежать подобной ситуации поз- 
воляет следующий набор рекомендаций: 

e Если вы не уверены, что дефект не был описан ранее, произведите поиск с 
помощью вашего инструментального средства управления жизненным цик- 
лом отчётов о дефектах. 

• Пишите максимально информативные краткие описания (т.к. поиск в первую 
очередь проводят по ним). Если на вашем проекте накопится множество де- 
фектов с краткими описаниями в стиле «Кнопка не работает», вы потратите 
очень много времени, раз за разом перебирая десятки таких отчётов в поис- 
ках нужной информации. 

• Используйте по максимуму возможности вашего инструментального сред- 
ства: указывайте в отчёте о дефекте компоненты приложения, ссылки на тре- 
бования, расставляйте теги и т.д. — всё это позволит легко и быстро сузить 
в будущем круг поиска. 

• Указывайте в подробном описании дефекта текст сообщений от приложения, 
если это возможно. По такому тексту можно найти даже тот отчёт, в котором 
остальная информация приведена в слишком общем виде. 

e Старайтесь по возможности участвовать в т.н. «собраниях по прояснению» 
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(clarification meetings), т.к. пусть вы и не запомните каждый дефект или KAX- 
дую пользовательскую историю дословно, но в нужный момент может воз- 
никнуть ощущение «что-то такое я уже слышал», которое заставит вас про- 
извести поиск и подскажет, что именно искать. 

e Если вы обнаружили какую-то дополнительную информацию, внесите её в 
уже существующий отчёт о дефекте (или попросите сделать это его автора), 
но не создавайте отдельный отчёт. 


Очевидность и понятность. Описывайте дефект так, чтобы у читающего 
ваш отчёт не возникло ни малейшего сомнения в том, что это действительно де- 
фект. Лучше всего это свойство достигается за счёт тщательного объяснения фак- 
тического и ожидаемого результата, а также указания ссылки на требование в поле 
«Подробное описание». 








Сравните: 
Плохое подробное описание Хорошее подробное описание 
Приложение не сообщает об обнаруженных | Приложение не уведомляет пользователя об 
подкаталогах в каталоге SOURCE_DIR. обнаруженных в каталоге SOURCE_DIR подка- 


талогах, что приводит к необоснованным ожи- 
даниям пользователями обработки файлов в 
таких подкаталогах. 

Асї: приложение начинает (продолжает) ра- 
боту, если в каталоге SOURCE_DIR находятся 
подкаталоги. 

Exp: в случае если в каталоге SOURCE_DIR 
приложение при запуске или в процессе работы 
обнаруживает пустой подкаталог, оно автома- 
тически его удаляет (логично ли это?), если же 
обнаружен непустой подкаталог, приложение 
прекращает работу с выводом сообщения 
«Моп-етру subfolder [имя подкаталога] т 
ЗОЧВСЕ_ РІВ folder detected. Remove it manu- 
ally or restart application with --force_file_opera- 
tions key to remove automatically.» 

Req: UR.56.BF.4.c. 














В первом случае после прочтения подробного описания очень хочется спро- 
сить: «И что? А оно разве должно уведомлять?» Второй же вариант подробного 
описания даёт чёткое пояснение, что такое поведение является ошибочным со- 
гласно текущему варианту требований. Более того, во втором варианте отмечен 
вопрос (а в идеале нужно сделать соответствующую отметку и в самом требова- 
нии), призывающий пересмотреть алгоритм корректного поведения приложения в 
подобной ситуации: т.е. мы не только качественно описываем текущую проблему, 
но и поднимаем вопрос о дальнейшем улучшении приложения. 


Прослеживаемость. Из содержащейся в качественном отчёте о дефекте ин- 
формации должно быть понятно, какую часть приложения, какие функции и какие 
требования затрагивает дефект. Лучше всего это свойство достигается правиль- 
ным использованием возможностей инструментального средства управления отчё- 
тами о дефектах: указывайте в отчёте о дефекте компоненты приложения, ссылки 
на требования, тест-кейсы, смежные отчёты о дефектах (похожих дефектах; зави- 
симых и зависящих от данного дефектах), расставляйте теги и т.д. 

Некоторые инструментальные средства даже позволяют строить визуальные 
схемы на основе таких данных, что позволяет управление прослеживаемостью 





324 Clarification meeting. А discussion that helps the customers achieve “advance clarity” — consensus оп the desired behavior ої 
each story — by asking questions and getting examples. [«Agile Testing», Lisa Crispin, Janet Gregory] 
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даже на очень больших проектах превратить из непосильной для человека задачи 
в тривиальную работу. 


Отдельные отчёты для каждого нового дефекта. Существует два незыб- 
лемых правила: 

e В каждом отчёте описывается ровно один дефект (если один и тот же де- 
фект проявляется в нескольких местах, эти проявления перечисляются в по- 
дробном описании). 

• При обнаружении нового дефекта создаётся новый отчёт. Нельзя для опи- 
сания нового дефекта править старые отчёты, переводя их в состояние «от- 
крыт заново». 


Нарушение первого правила приводит к объективной путанице, которую 
проще всего проиллюстрировать так: представьте, что в одном отчёте описано два 
дефекта, один из которых был исправлен, а второй — нет. В какое состояние пере- 
водить отчёт? Неизвестно. 

Нарушение второго правила вообще порождает хаос: мало того, что теряется 
информация о ранее возникавших дефектах, так к тому же возникают проблемы со 
всевозможными метриками и банальным здравым смыслом. Именно во избежание 
этой проблемы на многих проектах правом перевода отчёта из состояния «закрыт» 
в состояние «открыт заново» обладает ограниченный круг участников команды. 


Соответствие принятым шаблонам оформления и традициям. Как и в 
случае с тест-кейсами, с шаблонами оформления отчётов о дефектах проблем не 
возникает: они определены имеющимся образцом или экранной формой инстру- 
ментального средства управления жизненным циклом отчётов о дефектах. Но что 
касается традиций, которые могут различаться даже в разных командах в рамках 
одной компании, то единственный совет: почитайте уже готовые отчёты о дефек- 
тах, перед тем как писать свои. Это может сэкономить вам много времени и сил. 
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2.5.6. Логика создания эффективных отчётов о дефектах 


При создании отчёта о дефекте рекомендуется следовать следующему ал- 


горитму: 


0 
1. 
2. 
З 


> 


Обнаружить дефект ©. 

Понять суть проблемы. 

Воспроизвести дефект. 

Проверить наличие описания найденного вами дефекта в системе управле- 
ния дефектами. 

Сформулировать суть проблемы в виде «что сделали, что получили, что ожи- 
дали получить». 

Заполнить поля отчёта, начиная с подробного описания. 

После заполнения всех полей внимательно перечитать отчёт, исправив не- 
точности и добавив подробности. 

Ещё раз перечитать отчёт, т.к. в пункте 6 вы точно что-то упустили ©. 


Теперь — о каждом шаге подробнее. 


Понять суть проблемы 


Всё начинается именно с понимания происходящего с приложением. Только 


при наличии такого понимания вы сможете написать по-настоящему качественный 
отчёт о дефекте, верно определить важность дефекта и дать полезные рекоменда- 
ции по его устранению. В идеале отчёт о дефекте описывает именно суть про- 
блемы, а не её внешнее проявление. 


Сравните два отчёта об одной и той же ситуации (приложение «Конвертер 


файлов» не различает файлы и символические ссылки на файлы, что приводит к 
серии аномалий в работе с файловой системой). 


Плохой отчёт, при написании которого суть проблемы не понята: 











Краткое описание Подробное описание Шаги по воспроизведению _ 
Обрабатываются Иногда по непонятным причинам К сожалению, не удалось обнару- ~ 
файлы вне приложение обрабатывает случай- жить последовательность шагов, 
SOURCE_DIR. ные файлы вне каталога приводящих к появлению этого 

ЗОУВСЕ ВІА. дефекта. 


Асі: обрабатываются отдельные 
файлы вне SOURCE_DIR. 

Ехр: обрабатываются только 
файлы, находящиеся в 

















SOURCE ВОІВ. 
Req: ДС-2.1. 
` Воспро- | Важность Сроч- Симптом Воз- Комментарий 
ї изводи- ность мож- 
мость ность 
М обойти 
Иногда Высокая Высокая Некорректная | Нет 
операция 
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Хороший отчёт, при написании которого суть проблемы понята: 





Краткое описание 


Подробное описание 


Шаги по восп роизведению 








Приложение не раз- 
личает файлы и 
символические 
ссылки на файлы. 





Если в каталог SOURCE_DIR nome- 
стить символическую ссылку на файл, 
возникает следующее ошибочное по- 
ведение: 

а) Если символическая ссылка указы- 
вает на файл внутри ЅОЦОВСЕ ВІВ, 
файл обрабатывается дважды, а в 
ОЕТІМАТІОМ№ РІА перемещается как 
сам файл, так и символическая 
ссылка на него. 


6) Если символическая ссылка указы- 
вает на файл вне SOURCE_DIR, при- 
ложение обрабатывает этот файл, 
перемещает символическую ссылку и 
сам файл в ОЕЅТІМАТІОМ ВІВ, а 3a- 
тем продолжает обрабатывать 

файлы в каталоге, в котором изна- 
чально находился обработанный 
файл. 

Асї: приложение считает символиче- 
ские ссылки на файлы самими фай- 
лами (см. подробности выше). 

Ехр: в случае если в каталоге 
SOURCE_DIR приложение обнаружи- 
вает символическую ссылку, оно пре- 
кращает работу с выводом сообщения 
«Symbolic link [имя символической 
ссылки] м ЗОЧАСЕ_ ОІВ folder de- 
tected. Remove it manually ог restart ap- 
plication with --force_file_operations key 
to remove automatically.» 


Req: UR.56.BF.4.e. 


1. В произвольном месте CO- 
здать следующую структуру 
каталогов: 

/ЭВС/ 
/DST/ 
/XI 

2. Поместить в каталоги SRC n X 
несколько произвольных фай- 
лов допустимого формата и 
размера. 

3. Создать в каталоге ЗАС две 
символические ссылки: а) на 
любой из файлов внутри ката- 
лога SRC; б) на любой из 
файлов внутри каталога Х. 

4. Запустить приложение. 


Дефект: в каталог DST nepe- 
мещены как файлы, так и сим- 
волические ссылки; содержи- 
мое каталога Х обработано и 
перемещено в каталог DST. 


И РРР РОР РОР ГА 











< Воспро- | Важность Сроч- Симптом | Возмож- Комментарий 
изводи- ность ность 
мость обойти 
Всегда Высокая Обычная Некор- Нет Быстрый взгляд на код показал, 
ректная что вместо is_file() используется 
операция Не_ех!${5(). Похоже, проблема в 
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этом. Также этот дефект приво- 
дит к попытке обработать ката- 
логи как файлы (см. ВВ-999.99). 
В алгоритме обработки 
SOURCE_DIR явно есть логиче- 
ская ошибка: ни при каких усло- 
виях приложение не должно об- 
рабатывать файлы, находящиеся 
вне SOURCE_DIR, т.е. что-то не 
так с генерацией или проверкой 
полных имён файлов. 
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Воспроизвести дефект 


Это действие не только поможет в дальнейшем правильно заполнить поле 
«Воспроизводимость“”8», но и позволит избежать неприятной ситуации, в которой 
за дефект приложения будет принят некий кратковременный сбой, который (скорее 
всего) произошёл где-то в вашем компьютере или в иной части ИТ-инфраструктуры, 
не имеющей отношения к тестируемому приложению. 


Проверить наличие описания найденного вами дефекта 


Обязательно стоит проверить, нет ли в системе управления дефектами опи- 
сания именно того дефекта, который вы только что обнаружили. Это простое дей- 
ствие, не относящееся непосредственно к написанию отчёта о дефекте, но значи- 
тельно сокращающее количество отчётов, отклонённых с резолюцией «дубликат». 


Сформулировать суть проблемы 


Формулировка проблемы в виде «что сделали (шаги по воспроизведению), 
что получили (фактический результат в подробном описании), что ожидали полу- 
чить (ожидаемый результат в подробном описании)» позволяет не только подгото- 
вить данные для заполнения полей отчёта, но и ещё лучше понять суть проблемы. 

В общем же случае формула «что сделали, что получили, что ожидали полу- 
чить» хороша по следующим причинам: 

• Прозрачность и понятность: следуя этой формуле, вы готовите именно дан- 
ные для отчёта о дефекте, не скатываясь в пространные отвлеченные pac- 
суждения. 

e Лёгкость верификации дефекта: разработчик, используя эти данные, может 
быстро воспроизвести дефект, а тестировщик после исправления дефекта 
удостовериться, что тот действительно исправлен. 

• Очевидность для разработчиков: ещё до попытки воспроизведения дефекта 
видно, на самом ли деле описанное является дефектом, или тестировщик 
где-то ошибся, записав в дефекты корректное поведение приложения. 

• Избавление от лишней бессмысленной коммуникации: подробные ответы на 
«что сделали, что получили, что ожидали получить» позволяют решать про- 
блему и устранять дефект без необходимости запроса, поиска и обсуждения 
дополнительных сведений. 

e Простота: на финальных стадиях тестирования с привлечением конечных 
пользователей можно ощутимо повысить эффективность поступающей об- 
ратной связи, если объяснить пользователям суть этой формулы и попро- 
сить их придерживаться её при написании сообщений об обнаруженных про- 
блемах. 


Информация, полученная на данном этапе, становится фундаментом для 
всех дальнейших действий по написанию отчёта. 


Заполнить поля отчёта 


Поля отчёта о дефекте мы уже рассмотрели ранее”, сейчас лишь подчерк- 
нём, что начинать лучше всего с подробного описания, т.к. в процессе заполнения 
этого поля может выявиться множество дополнительных деталей, а также появятся 
мысли по поводу формулирования сжатого и информативного краткого описания. 

Если вы понимаете, что для заполнения какого-то поля у вас не хватает дан- 
ных, проведите дополнительное исследование. Если и оно не помогло, опишите в 
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соответствующем поле (если оно текстовое), почему вы затрудняетесь с его запол- 
нением, или (если поле представляет собой список) выберите значение, которое, 
на ваш взгляд, лучше всего характеризует проблему (в некоторых случаях инстру- 
ментальное средство позволяет выбрать значение наподобие «неизвестно», тогда 
выберите его). 

Если у вас нет идей по поводу устранения дефекта, или он настолько тривиа- 
лен, что не нуждается в подобных пояснениях, не пишите в комментариях «текст 
ради текста»: комментарии вида «рекомендую устранить этот дефект» не просто 
бессмысленны, но ещё и раздражают. 


Перечитать отчёт (и ещё раз перечитать отчёт) 


После того как всё написано, заполнено и подготовлено, ещё раз внима- 
тельно перечитайте написанное. Очень часто вы сможете обнаружить, что в про- 
цессе доработки текста где-то получились логические нестыковки или дублирова- 
ние, где-то вам захочется улучшить формулировки, где-то что-то поменять. 

Идеал недостижим, и не стоит тратить вечность на один отчёт о дефекте, но 
и отправлять невычитанный документ — тоже признак дурного тона. 


осле оформления отчёта о дефекте рекомендуется дополнительно ис- 


следовать ту область приложения, в которой вы только что обнаружили | 
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2.5.7. Типичные ошибки при написании отчётов о дефектах 
Перед прочтением этого текста рекомендуется перечитать раздел с описа- 
нием типичных ошибок при составлении тест-кейсов и чек-листови5”, т.к. многие 
описанные там проблемы актуальны и для отчётов о дефектах (ведь и то, и другое 
= специфическая техническая документация). 


Ошибки оформления и формулировок 


Плохие краткие описания (ѕиттагу). Формально эта проблема относится 
к оформлению, но фактически она куда опаснее: ведь чтение отчёта о дефекте и 
осознание сути проблемы начинается именно с краткого описания. Ещё раз напом- 
ним его суть: 
e Отвечает на вопросы «что?», «где?», «при каких условиях?». 
• Должно быть предельно кратким. 
• Должно быть достаточно информативным для понимания сути проблемы. 


Посмотрите на эти краткие описания и попробуйте ответить себе на вопрос 
о том, что за проблема возникает, где она возникает, при каких условиях она воз- 
никает: 
• «Неожиданное прерывание». 
«Найдено 19 элементов». 
«Поиск по всем типам файлов». 
«Неинформативная ошибка». 
«В приложении красный шрифт». 
«Error when entering just the пате of computer disk ог folder». 
«No reaction to 'Enter' key». 


Иногда ситуацию спасает поле «подробное описание», из которого можно по- 
нять суть проблемы, но даже в этом случае сначала нужно приложить немало уси- 
лий, чтобы соотнести такое краткое описание с подробным, где представлено со- 
вершенно иное и иначе. 

Перечитайте ещё раз раздел про формулировку качественных кратких опи- 
саний“ 72}, 


Идентичные краткое и подробное описания (summary и description). Да, 
изредка бывают настолько простые дефекты, что для них достаточно одного крат- 
кого описания (например, «Опечатка в имени пункта главного меню “File” (сейчас 
“ЕШе”)»), но если дефект связан с неким более-менее сложным поведением прило- 
жения, стоит продумать как минимум три способа описания проблемы: 

e краткий для поля «краткое описание» (его лучше формулировать в самом 
конце размышлений); 

• подробный для поля «подробное описание» (поясняющий и расширяющий 
информацию из «краткого описания»); 

• ещё один краткий для последнего шага в шагах по воспроизведению де- 
фекта. 


И это не интеллектуальные игры от переизбытка свободного времени, это 
вполне рабочий инструмент для формирования понимания сути проблемы (по- 
верьте, вы едва ли сможете объяснить тремя разными способами то, что не пони- 
маете). 
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Отсутствие в подробном описании явного указания фактического ре- 
зультата, ожидаемого результата и ссылки на требование, если они важны, и 
их представляется возможным указать. 

Да, для мелочей наподобие опечаток в надписях этого можно не делать (и 
всё равно: при наличии времени лучше написать). 

Но что можно понять из отчёта о дефекте, в кратком и подробном описании 
которого сказано только «приложение показывает содержимое ОрепхХМ!-файлов»? 
А что, не должно показывать? В чём вообще проблема? Ну, показывает и показы- 
вает — разве это плохо? Ах, оказывается (!), приложение должно не показывать 
содержимое этих файлов, а открывать их с помощью соответствующей внешней 
программы. Об этом можно догадаться из опыта. Но догадка — плохой помощник в 
случае, когда надо переписывать приложение, — можно сделать только хуже. Это 
также можно (наверное) понять, вдумчиво читая требования. Но давайте будем ре- 
алистами: отчёт о дефекте будет отклонён с резолюцией «описанное поведение не 
является дефектом» («пої а бид»). 


Игнорирование кавычек, приводящее к искажению смысла. Как вы пой- 
мёте такое краткое описание, как «запись исчезает при наведении мыши»? Какая- 
то запись исчезает при наведении мыши? А вот и нет, оказывается, «поле “Запись” 
исчезает при наведении мыши». Даже если не дописать слово «поле», кавычки под- 
скажут, что имеется в виду имя собственное, т.е. название некоего элемента. 


Общие проблемы с формулировками фраз на русском и английском 
языках. Да, нелегко сразу научиться формулировать мысль одновременно очень 
кратко и информативно, но не менее сложно читать подобные творения (цитаты 
дословные): 

e «Поиск не работает нажатием кнопки Enter». 

e «По умолчанию в поле где искать стоит +». 

• «При поиске файлов в обширном каталоге приложение ненадолго "зави- 
сает"». 

e «При закрытии ошибки программа закрывается». 

e «The application doesn't work with те from keyboard Бу the user т те field "What 
to search"». 


Лишние пункты в шагах воспроизведения. Не стоит начинать «с сотворе- 
ния мира», большинство проектной команды достаточно хорошо знает приложение, 
чтобы «опознать» его ключевые части, потому — сравните: 











Плохо Хорошо 
1. Запустить приложение. 1. Создать или открыть файл с тремя и более 
2. Открыть пункт меню «Файл». непустыми страницами. 
3. Выбрать пункт меню «Новый». 2. Выбрать «Файл» -> «Печать» -> «Пара- 
4. Заполнить текстом не менее трёх страниц. метры» -> «Двусторонняя печать» -> «Нет». 
5. Открыть пункт меню «Файл». 3. Распечатать документ на принтере, под- 
6. Открыть подпункт меню «Печать». держивающем дуплексную печать. 
7. Открыть вкладку «Параметры печати». 
8. Выбрать в списке «Двусторонняя печать» Дефект: печать по-прежнему двусторонняя. 
значение «Нет». 
9. Распечатать документ на принтере, под- 
держивающем дуплексную печать. 
Дефект: печать по-прежнему двусторонняя. 
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Копии экрана в виде «копий всего экрана целиком». Чаще всего нужно 
сделать копию какого-то конкретного окна приложения, а не всего экрана — тогда 
поможет АЌ+Ргіпібсгееп. Даже если важно захватить больше, чем одно окно, прак- 
тически любой графический редактор позволяет отрезать ненужную часть кар- 
тинки. 


Копии экрана, на которых не отмечена проблема. Если обвести проблем- 
ную область красной линией, это в разы повысит скорость и простоту понимания 
сути проблемы в большинстве случаев. 









_Копии экрана и иные артефакты, размещённые на сторонних серве- 
рах. Эта ошибка заслуживает особого упоминания: категорически запре- | 
-LEHO использовать для прикрепления к отчёту о дефекте копий экрана n 
других файлов ставшие распространёнными в последнее время сервисы · 
‚ обмена изображениями, файлами и т.д. Причин здесь две: 
© в большинстве случаев на размещение изображения или иного файла | 
’ натаких сервисах есть ограничения по времени хранения и/или количе- 

ству обращений (скачиваний) — иными словами, через некоторое время | 
‚ файл может стать недоступным; 
+ размещение информации о проекте на сторонних сервисах является | 
’ раскрытием конфиденциальной информации, права на которую принад- ' 
’ Лежат заказчику. [ 
Поэтому для хранения любых подобных артефактов следует использо- | 
вать саму систему управления дефектами. Если в силу неких причин Ta- 
‚ ковая не используется, все вложения стоит разместить прямо в том доку- | 
менте, в котором вы описываете дефект (изображения можно разместить | 
‚ просто «в виде картинок», иные артефакты — в виде внедрённого доку- | 





Откладывание написания отчёта «на потом». Стремление сначала найти 
побольше дефектов, а уже потом их описывать приводит к тому, что какие-то важ- 
ные детали (а иногда и сами дефекты!) забываются. Если «на потом» измеряется 
не минутами, а часами или даже днями, проектная команда не получает важную 
информацию вовремя. Вывод простой: описывайте дефект сразу же, как только об- 
наружили его. 


Пунктуационные, орфографические, синтаксические и им подобные 
ошибки. Без комментариев. 


Логические ошибки 


Выдуманные дефекты. Одной из наиболее обидных для тестировщика при- 
чин отклонения отчёта о дефекте является так называемое «описанное поведение 
не является дефектом» («пої а бид»), когда по какой-то причине корректное пове- 
дение приложения описывается как ошибочное. 

Но ещё хуже, когда «якобы ожидаемое поведение» просто... придумывается 
из головы. То есть нигде в требованиях не сказано, что приложение должно что-то 
такое делать, но при этом создаётся отчёт о дефекте из-за того, что приложение 
этого не делает. И ладно бы это были некие спорные случаи или случайно попав- 
шие в отчёты о дефектах предложения по улучшению, но нет — от приложения 
начинают требовать каких-то совершенно нелогичных, нерациональных, безумных 
вещей. Откуда это? Зачем? Просто не делайте так. 
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Отнесение расширенных возможностей приложения к дефектам. Самым 
ярким примером этого случая является описание как дефекта того факта, что при- 
ложение запускается под операционными системами, не указанными явно в списке 
поддерживаемых. Лишь в очень редких случаях при разработке неких системных 
утилит и тому подобного ПО, крайне зависящего от версии ОС и потенциально спо- 
собного «поломать» неподдерживаемую, это можно считать ошибкой (с точки зре- 
ния общего здравого смысла такое приложение действительно должно показывать 
предупреждение или даже сообщение об ошибке и завершать работу на неподдер- 
живаемой ОС). Но что плохого в том, что детская игрушка запустилась на ОС 
предыдущего поколения? Это реально проблема?! Сомнительно. 


Неверно указанные симптомы. Это не смертельно, всегда можно подпра- 
вить, но если изначально отчёты будут сгруппированы по симптомам, их неверное 
указание создаёт множество раздражающих неудобств. 


Чрезмерно заниженные (или завышенные) важность и срочность. С 
этой бедой достаточно эффективно борются проведением общих собраний и пере- 
смотром отчётов о дефектах силами всей команды (или хотя бы нескольких чело- 
век), но если эти показатели занижены именно чрезмерно, есть высокая вероят- 
ность, что пройдёт очень много времени, прежде чем до такого отчёта просто дой- 
дёт очередь на следующих собраниях по пересмотру. 


Концентрация на мелочах в ущерб главному. Здесь стоит упомянуть хре- 
стоматийный пример, когда тестировщик нашёл проблему, приводящую к краху 
приложения с потерей пользовательских данных, но записал её как косметический 
дефект (в сообщении об ошибке, которое «перед смертью» показывало приложе- 
ние, была опечатка). Всегда думайте о том, как произошедшая с приложением не- 
приятность повлияет на пользователей, какие сложности они могут из-за этого ис- 
пытать, насколько это для них важно, — тогда шанс увидеть реальную проблему 
резко повышается. 


Техническая безграмотность. Да, вот так безапелляционно и жёстко. В не- 
которых случаях она просто вызывает грустную улыбку, но в некоторых... Пред- 
ставьте себе такое краткое описание (оно же идентично продублировано в подроб- 
ном, т.е. это и есть всё описание дефекта): «Количество найденных файлов не со- 
ответствует реальной глубине вложенности каталога». А что, должно? Это ведь по- 
чти то же самое, что «цвет кошки не соответствует её размеру». 

Ещё несколько показательных примеров (это примеры из разных, никак не 
связанных между собой отчётов о дефектах): 

e Краткое описание: «По умолчанию выбран каталог аудиозаписи». (На самом 
деле в выпадающем списке «Что искать» выбрано значение «Аудиофайлы».) 

• Пояснение в подробном описании: «У каталога не может быть даты и вре- 
мени созданиях. (Хм. Может.) 

e Ожидаемый результат: «Приложение верно распознало неподдерживаемую 
файловую систему и показало список файлов». (Ого! С этим приложением, 
скорее всего, можно будет и на философские темы побеседовать, если оно 
способно на такую магию.) 
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Указание в шагах воспроизведения информации, неважной для воспро- 
изведения ошибки. Стремление прописать всё максимально подробно иногда 
принимает нездоровую форму, когда в отчёт о дефекте начинает попадать чуть ли 
не информация о погоде за окном и курс национальной валюты. Сравните: 

















Плохо Хорошо 

1. Создать на диске «Ј:» каталог «Data». 1. В произвольном месте на локальном диске 
2. Разместить в созданном каталоге «Data» разместить один (или более) файл с рас- 

прилагаемые файлы «song1.mp3» разме- ширением «.тр3». 

ром 999.99 Kb и «ѕопд2.трЗ» размером 2. Установить параметры поиска («Что ис- 

888.88 Kb. кать» -> «Аудиофайлы», «Где искать» -> 
3. В поле «Где искать» указать «Ј\Оаїа». место расположения файла(ов) из пункта 
4. В выпадающем списке «Что искать» вы- 1). 

брать «Аудиофайлы». 3. Произвести поиск. 
5. Нажать кнопку «Искать». 

Дефект: приложение не обнаруживает 
Дефект: указанные в пункте 2 файлы не файлы с расширением «.тр3З». 
найдены. 





Действительно ли для воспроизведения дефекта важно, чтобы поиск произ- 
водился на диске «Ј:»? Действительно ли важно производить поиск именно файлов 
с такими именами и размерами в таком каталоге? Возможно, в некоем бесконечно 
маловероятном случае и да, тогда вопрос снимается. Но, скорее всего, это совер- 
шенно не важно, и нет никакой необходимости записывать эту информацию. Для 
большей уверенности можно провести дополнительное исследование. 


Отсутствие в шагах воспроизведения информации, важной для воспро- 
изведения дефекта. Нет, мы не издеваемся, этот пункт действительно строго про- 
тивоположен предыдущему. Дефекты бывают разными. Очень разными. Иногда ка- 
кой-то ключевой «мелочи» не хватит, чтобы разработчику удалось воспроизвести 
дефект или даже просто понять его суть. Несколько реальных примеров (подчёрк- 
нуты те детали, отсутствие которых долго не позволяло воспроизвести дефект): 

• Приложение не сохраняло пользовательские настройки в случае, если в пути 

к каталогу для их сохранения были пробелы (два и более подряд пробела). 

• Приложение некорректно завершало работу при открытии файлов, размер 
которых не позволял прочитать их целиком в оперативную память, доступ- 
ный объём которой, в свою очередь, определяется значением параметра 
memory_limit в настройках среды исполнения. 

• Приложение отображало неверную статистику работы пользователей, если 

в системе был хотя бы один пользователь, роль которого не была явно ука- 

зана (МОШ -значение в таблице БД, неверная работа подзапроса). 


Как понять, насколько подробно надо описывать такие детали? Исследова- 
нием. Мало просто обнаружить некий единичный случай неверного поведения при- 
ложения, нужно понять закономерность такого поведения и его источник. Тогда не- 
обходимая степень детализации становится очевидной. 

Сюда же можно отнести пресловутую воспроизводимость «иногда». Нужно 
продолжать искать причины, смотреть код, консультироваться с коллегами, прово- 
дить дополнительные тесты, исследовать похожую функциональность в других ча- 
стях приложения, исследовать аналогичные приложения, «гуглить» и т.д. и т.п. Да, 
часть дефектов оказывается сильнее даже самых упорных тестировщиков, но вот 
процент таких дефектов можно очень сильно приблизить к нулю. 
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Игнорирование т.н. «последовательных дефектов». Иногда один дефект 
является следствием другого (допустим, файл повреждается при передаче на сер- 
вер, а затем приложение некорректно обрабатывает этот повреждённый файл). Да, 
если файл будет передан без повреждений, второй дефект может не проявиться. 
Но может и проявиться в другой ситуации, т.к. проблема никуда не исчезла: прило- 
жение некорректно обрабатывает повреждённые файлы. Потому стоит описать оба 
дефекта. 
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2.6. Оценка трудозатрат, планирование и отчётность 


2.6.1. Планирование и отчётность 


В главе «Логика создания эффективных проверок» мы на примере «Кон- 
вертера файлов» рассуждали о том, как при минимальных трудозатратах получить 
максимальный эффект от тестирования. Это было достаточно просто, т.к. наше 
приложение смехотворно по своим масштабам. Но давайте представим, что тести- 
ровать приходится реальный проект, где требования в «страничном эквиваленте» 
занимают сотни и даже тысячи страниц. Также давайте вспомним главу «Подроб- 
ная классификация тестирования» ®% с её несколькими десятками видов тестирова- 
ния (и это без учёта того факта, что их можно достаточно гибко комбинировать, 
получая новые варианты) и подумаем, как применить все эти знания (и открывае- 
мые ими возможности) в крупном проекте. 

Даже если допустить, что мы идеально знаем все технические аспекты пред- 
стоящей работы, неотвеченными остаются такие вопросы, как: 

e Когда и с чего начать? 

e Всё ли необходимое для выполнения работы у нас есть? Если нет, где взять 
недостающее? 
В какой последовательности выполнять разные виды работ? 
Как распределить ответственность между участниками команды? 
Как организовать отчётность перед заинтересованными лицами? 
Как объективно определять прогресс и достигнутые успехи? 
Как заранее увидеть возможные проблемы, чтобы успеть их предотвратить? 
Как организовать нашу работу так, чтобы при минимуме затрат получить мак- 
симум результата? 


Эти и многие подобные им вопросы уже лежат вне технической области — 
они относятся к управлению проектом. Эта задача сама по себе огромна, потому 
мы рассмотрим лишь малую её часть, с которой многим тестировщикам приходится 
иметь дело, — планирование и отчётность. 

Вспомним жизненный цикл тестирования?”7: каждая итерация начинается с 
планирования и заканчивается отчётностью, которая становится основой для пла- 
нирования следующей итерации — и так далее (см. рисунок 2.6.а). Таким образом, 
планирование и отчётность находятся в тесной взаимосвязи, и проблемы с одним 
из этих видов деятельности неизбежно приводят к проблемам с другим видом, а в 
конечном итоге и к проблемам с проектом в целом. 





ны 


Отчётность Планирование 

















Работа 


Рисунок 2.6.а — Взаимосвязь (взаимозависимость) планирования и отчётности 
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Если выразить эту мысль чётче и по пунктам, получается: 

e Без качественного планирования не ясно, кому и что нужно делать. 

e Когда не ясно, кому и что нужно делать, работа выполняется плохо. 

e Когда работа выполнена плохо и не ясны точные причины, невозможно CAE- 
лать правильные выводы о том, как исправить ситуацию. 

e Без правильных выводов невозможно создать качественный отчёт о резуль- 
татах работы. 

• Без качественного отчёта о результатах работы невозможно создать каче- 
ственный план дальнейшей работы. 

» Всё. Порочный круг замкнулся. Проект умирает. 


Казалось бы, так и в чём же сложность? Давайте будем хорошо планировать 
и писать качественные отчёты — и всё будет хорошо. Проблема в том, что соответ- 
ствующие навыки развиты в достаточной мере у крайне небольшого процента лю- 
дей. Если вы не верите, вспомните, как учили материал в ночь перед экзаменом, 
как опаздывали на важные встречи и... повторяли это раз за разом, так и не сделав 
выводов. (Если в вашей жизни такого не было, можно надеяться, что вам повезло 
оказаться в том небольшом проценте людей, у которых соответствующие навыки 
развиты хорошо.) 

Корень проблемы состоит в том, что планированию и отчётности в школах и 
университетах учат достаточно поверхностно, при этом (увы) на практике часто вы- 
холащивая эти понятия до пустой формальности (планов, на которые никто не 
смотрит, и отчётов, которые никто не читает; опять же, кому-то повезло увидеть 
строго обратную ситуацию, но явно немногим). 

Итак, к сути. Сначала рассмотрим классические определения. 





Планирование (planning?) — непрерывный процесс принятия ynpaBneH- | 


(ш) б È 5 | 
(т) ‚ ческих решений и методической организации усилий по их реализации с 
| целью обеспечения качества некоторого процесса на протяжении дли- 





К высокоуровневым задачам планирования относятся: 
снижение неопределенности; 

повышение эффективности; 

улучшение понимания целей; 

создание основы для управления процессами. 







‚ Отчётность (reporting?) — сбор и распространение информации о pe- | 
‚ зультатах работы (включая текущий статус, оценку прогресса и прогноз 





К высокоуровневым задачам отчётности относятся: 

e сбор, агрегация и предоставление в удобной для восприятия форме объек- 
тивной информации о результатах работы; 

• формирование оценки текущего статуса и прогресса (в сравнении с планом); 

e обозначение существующих и возможных проблем (если такие есть); 

• формирование прогноза развития ситуации и фиксация рекомендаций по 
устранению проблем и повышению эффективности работы. 





325 Planning is а continuous process ої making entrepreneurial decisions with ап eye їо the future, апа methodically organizing the 
effort needed to carry out these decisions. There are four basic reasons for project planning: to eliminate or reduce uncertainty; 
to improve efficiency of the operation; to obtain a better understanding of the objectives; to provide a basis for monitoring and 
controlling work. [«Project Management: A Systems Approach to Planning, Scheduling, and Controlling», Harold Kerzner] 

326 Reporting — collecting and distributing performance information (including status reporting, progress measurement, and fore- 
casting). [РМВОК, 3" edition] 
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Как и было упомянуто ранее, планирование и отчётность относятся к области 
управления проектом, которая выходит за рамки данной книги. 





Если вас интересуют детали, рекомендуется ознакомиться с двумя фун 


| даментальными источниками информации: 


| e «Project Management: А Systems Approach to Planning, Scheduling, апа 
Controlling», Harold Kerzner. 





Мы же переходим K более конкретным вещам, с которыми приходится рабо- 
тать (пусть и на уровне использования, а не создания) даже начинающему тести- 
ровщику. 
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2.6.2. Тест-план и отчёт о результатах тестирования 


Тест-план 





` Тест-план (test р!ап27) — документ, описывающий и регламентирующий | 
‚ перечень работ по тестированию, а также соответствующие техники и NOA- 
‚ ходы, стратегию, области ответственности, ресурсы, расписание и ключе- | 





вые даты. 


К низкоуровневым задачам планирования в тестировании относятся: 

оценка объёма и сложности работ; 

определение необходимых ресурсов и источников их получения; 
определение расписания, сроков и ключевых точек; 

оценка рисков и подготовка превентивных контрмер; 

распределение обязанностей и ответственности; 

согласование работ по тестированию с деятельностью участников проектной 
команды, занимающихся другими задачами. 


Как и любой другой документ, тест-план может быть качественным или обла- 
дать недостатками. Качественный тест-план обладает большинством свойств каче- 
ственных требований“, а также расширяет их набор следующими пунктами: 

• Реалистичность (запланированный подход реально выполним). 

e Гибкость (качественный тест-план не только является модифицируемым с 
точки зрения работы с документом, но и построен таким образом, чтобы при 
возникновении непредвиденных обстоятельств допускать быстрое измене- 
ние любой из своих частей без нарушения взаимосвязи с другими частями). 

e Согласованность с общим проектным планом и иными отдельными планами 
(например, планом разработки). 


Тест-план создаётся в начале проекта и дорабатывается по мере необходи- 
мости на протяжении всего времени жизни проекта при участии наиболее квалифи- 
цированных представителей проектной команды, задействованных в обеспечении 
качества. Ответственным за создание тест-плана, как правило, является ведущий 
тестировщик («тест-лид»). 


В общем случае тест-план включает следующие разделы (примеры их 
наполнения будут показаны далее, потому здесь — только перечисление). 

e Цель (purpose). Предельно краткое описание цели разработки приложения 
(частично это напоминает бизнес-требования9, но здесь информация noga- 
ётся в ещё более сжатом виде и в контексте того, на что следует обращать 
первостепенное внимание при организации тестирования и повышения каче- 
ства). 

e Области, подвергаемые тестированию (features to be tested). Перечень 
функций и/или нефункциональных особенностей приложения, которые будут 
подвергнуты тестированию. В некоторых случаях здесь также приводится 
приоритет соответствующей области. 

e Области, не подвергаемые тестированию (features пої їо be tested). Пере- 
чень функций и/или нефункциональных особенностей приложения, которые 
не будут подвергнуты тестированию. Причины исключения той или иной об- 





327 Test plan. А document describing {Не scope, approach, resources апа schedule of intended test activities. It identifies amongst 
others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test 
environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks 
requiring contingency planning. It is a record of the test planning process. [ISTQB Glossary] 
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ласти из списка тестируемых могут быть самыми различными — от пре- 
дельно низкой их важности для заказчика до нехватки времени или иных ре- 
сурсов. Этот перечень составляется, чтобы у проектной команды и иных за- 
интересованных лиц было чёткое единое понимание, что тестирование та- 
ких-то особенностей приложения не запланировано — такой подход позво- 
ляет исключить появление ложных ожиданий и неприятных сюрпризов. 

e Тестовая стратегия (test strategy?) и подходы (test approach). Описание 
процесса тестирования с точки зрения применяемых методов, подходов, ви- 
дов тестирования, технологий, инструментальных средств ит.д. 

e Критерии (criteria). Этот раздел включает следующие подразделы: 

о Приёмочные критерии, критерии качества (acceptance сйепазз) — 
любые объективные показатели качества, которым разрабатываемый 
продукт должен соответствовать с точки зрения заказчика или пользо- 
вателя, чтобы считаться готовым к эксплуатации. 

о Критерии начала тестирования (entry сщепазз!) — перечень условий, 
при выполнении которых команда приступает к тестированию. Нали- 
чие этого критерия страхует команду от бессмысленной траты усилий 
в условиях, когда тестирование не принесёт ожидаемой пользы. 

о Критерии приостановки тестирования (suspension сгїегіазз2) — ne- 
речень условий, при выполнении которых тестирование приостанав- 
ливается. Наличие этого критерия также страхует команду от бессмыс- 
ленной траты усилий в условиях, когда тестирование не принесёт ожи- 
даемой пользы. 

о Критерии возобновления тестирования (resumption сгїегіаззз) — ne- 
речень условий, при выполнении которых тестирование возобновля- 
ется (как правило, после приостановки). 

о Критерии завершения тестирования (exit сщепазз“) — перечень 
условий, при выполнении которых тестирование завершается. Нали- 
чие этого критерия страхует команду как от преждевременного прекра- 
щения тестирования, так и от продолжения тестирования в условиях, 
когда оно уже перестаёт приносить ощутимый эффект. 

e Ресурсы (resources). В данном разделе тест-плана перечисляются все необ- 
ходимые для успешной реализации стратегии тестирования ресурсы, кото- 
рые в общем случае можно разделить на: 

о программные ресурсы (какое ПО необходимо команде тестировщиков, 
сколько копий и с какими лицензиями (если речь идёт о коммерческом 
ПО)); 





328 Test strategy. А high-level description о the test levels їо be performed апа the testing within {позе levels (group о test activities 
that are organized and managed together, e.g. component test, integration test, system test and acceptance test) for an organi- 
zation or program (one or more projects). [ISTQB Glossary] 

329 Test approach. The implementation of the test strategy for a specific project. It typically includes the decisions made that follow 
based on the (test) ргојесіѕ goal and the risk assessment carried out, starting points regarding the test process, the test design 
techniques to be applied, exit criteria and test types to be performed. [ISTQB Glossary] 

330 Acceptance criteria. The exit criteria that a component or system must satisfy in order to be accepted by a user, customer, or 
other authorized entity. [ISTQB Glossary] 

331 Entry criteria. The set of generic and specific conditions for permitting a process to go forward with a defined task, e.g. test phase. 
The purpose of entry criteria is to prevent a task from starting which would entail more (wasted) effort compared to the effort 
needed to remove the failed entry criteria. [ISTQB Glossary] 

332 Suspension criteria. The criteria used to (temporarily) stop all or a portion of the testing activities on the test items. [ISTQB 
Glossary] 

333 Resumption criteria. The criteria used to restart all or a portion of the testing activities that were suspended previously. [ISTQB 
Glossary] 

334 Exit criteria. The set of generic and specific conditions, agreed upon with the stakeholders for permitting a process to be officially 
completed. The purpose of exit criteria is to prevent a task from being considered completed when there are still outstanding 
parts of the task which have not been finished. Exit criteria are used to report against and to plan when to stop testing. [ISTQB 
Glossary] 
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о аппаратные ресурсы (какое аппаратное обеспечение, в каком количе- 
стве и ккакому моменту необходимо команде тестировщиков); 

о человеческие ресурсы (сколько специалистов какого уровня и со зна- 
ниями в каких областях должно подключиться к команде тестировщи- 
ков в тот или иной момент времени); 

о временные ресурсы (сколько по времени займёт выполнение тех или 
иных работ); 

о финансовые ресурсы (в какую сумму обойдётся использование имею- 
щихся или получение недостающих ресурсов, перечисленных в 
предыдущих пунктах этого списка); во многих компаниях финансовые 
ресурсы могут быть представлены отдельным документом, т.к. явля- 
ются конфиденциальной информацией. 

e Расписание (test ѕсһеаиіеззѕ). Фактически это календарь, в котором указано, 
что и к какому моменту должно быть сделано. Особое внимание уделяется 
т.н. «ключевым точкам» (milestones), к моменту наступления которых должен 
быть получен некий значимый ощутимый результат. 

e Роли и ответственность (roles апа responsibility). Перечень необходимых 
ролей (например, «ведущий тестировщик», «эксперт по оптимизации произ- 
водительности») и область ответственности специалистов, выполняющих 
эти роли. 

e Оценка рисков (risk evaluation). Перечень рисков, которые с высокой Bepo- 
ятностью могут возникнуть в процессе работы над проектом. По каждому 
риску даётся оценка представляемой им угрозы и приводятся варианты вы- 
хода из ситуации. 

e Документация (documentation). Перечень используемой тестовой докумен- 
тации с указанием, кто и когда должен её готовить и кому передавать. 

e Метрики (теїігісѕззе). Числовые характеристики показателей качества, CNO- 
собы их оценки, формулы и т.д. На этот раздел, как правило, формируется 
множество ссылок из других разделов тест-плана. 


Метрики в тестировании являются настолько важными, что о них мы погово- 
рим отдельно. Итак. 





Метрика (metric?) — числовая характеристика показателя качества. Mo- 
жет включать описание способов оценки и анализа результата. 








Сначала поясним важность метрик на тривиальном примере. Представьте, 
что заказчик интересуется текущим положением дел и просит вас кратко охаракте- 
ризовать ситуацию с тестированием на проекте. Общие слова в стиле «всё хо- 
рошо», «всё плохо», «нормально» и тому подобное его, конечно, не устроят, т.к. они 
предельно субъективны и могут быть крайне далеки от реальности. И совсем иначе 
выглядит ответ наподобие такого: «Реализовано 79 % требований (в т.ч. 94 % важ- 
ных), за последние три спринта тестовое покрытие выросло с 63 % до 71 %, а общий 
показатель прохождения тест-кейсов вырос с 85 % до 89 %. Иными словами, мы 
полностью укладываемся в план по всем ключевым показателям, а по разработке 
даже идём с небольшим опережением». 





335 Test schedule. А list of activities, tasks ог events of the test process, identifying their intended start апа finish dates and/or times, 
and interdependencies. [ISTQB Glossary] 


336 Metric. A measurement scale and the method used for measurement. [ISTQB Glossary] 
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Чтобы оперировать всеми этими числами (а они нужны не только для отчёт- 


ности, но и для организации работы проектной команды), их нужно как-то вычис- 
лить. Именно это и позволяют сделать метрики. Затем вычисленные значения 
можно использовать для: 


принятия решений о начале, приостановке, возобновлении или прекращении 
тестирования (см. выше раздел «Критерии» тест-плана); 

определения степени соответствия продукта заявленным критериям каче- 
ства; 

определения степени отклонения фактического развития проекта от плана; 
выявления «узких мест», потенциальных рисков и иных проблем; 

оценки результативности принятых управленческих решений; 

подготовки объективной информативной отчётности; 

и Т.Д. 


Метрики могут быть как прямыми (не требуют вычислений), так и расчётными 


(вычисляются по формуле). Типичные примеры прямых метрик — количество раз- 
работанных тест-кейсов, количество найденных дефектов и т.д. В расчётных мет- 
риках могут использоваться как совершенно тривиальные, так и довольно сложные 
формулы (см. таблицу 2.6.1). 


Таблица 2.6.1 — Примеры расчётных метрик 





Простая расчётная метрика Сложная расчётная метрика 








Минимальные границы значений: 


Success R 
Pelo h 0 SC — 5 MaxLevel (Тьезег О "Level 
T 7 qTotal 100%, где Т — 21етеї Ба геш. где 


SP y А 
Т” — процентный показатель успеш- | TSC — интегральная метрика прохождения тест-кейсов 


ного прохождения тест-кейсов, во взаимосвязи с требованиями и дефектами, 

Т 5655 — количество успешно выпол- | Т — степень важности тест-кейса, 

ненных тест-кейсов, I — количество выполнений тест-кейса, 

Total _. общее количество выполнен- | р, „„„, — степень важности требования, проверяемого 
ных тест-кейсов. тест-кейсом, 


В, гре — Количество дефектов, обнаруженных тест-кей- 


м. 
• Начальная фаза проекта: 10 %. ca 

e Основная фаза проекта: 40 %. Способ анализа: 

• Финальная фаза проекта: 85 %. ® Идеальным состоянием является непрерывный рост 


значения Т°С. 

e В случае отрицательной динамики уменьшение значе- 
ния Т5Сна 15 % и более за последние три спринта MO- 
жет трактоваться как недопустимое и являться доста- 
точным поводом для приостановки тестирования. 











В тестировании существует большое количество общепринятых метрик, мно- 


гие из которых могут быть собраны автоматически с использованием инструмен- 
тальных средств управления проектами. Напримерзз7: 


процентное отношение (не) выполненных тест-кейсов ко всем имеющимся; 
процентный показатель успешного прохождения тест-кейсов (см. «Простая 
расчётная метрика» в таблице 2.6.1); 

процентный показатель заблокированных тест-кейсов; 

плотность распределения дефектов; 

эффективность устранения дефектов; 

распределение дефектов по важности и срочности; 

ит.д. 





337 «Important Software Test Metrics and Measurements — Explained with Examples апа Graphs» [http:/www.softwaretest- 
inghelp.com/software-test-metrics-and-measurements/] 
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Как правило, при формировании отчётности нас будет интересовать не 
только текущее значение метрики, но и её динамика во времени, которую очень 
удобно изображать графически (что тоже могут выполнять автоматически многие 
средства управления проектами). 

Некоторые метрики могут вычисляться на основе данных о расписании, 
например метрика «сдвига расписания»: 


DaysToDeadline 


ScheduleSlippage = — 1, где 


№ еаеарау$ 

5спейще5 Прраде — значение сдвига расписания, 

DaysToDeadline — количество дней до запланированного завершения работы, 
NeededDays — количество дней, необходимое для завершения работы. 
Значение 5спейше5 Прраде не должно становиться отрицательным. 


Таким образом, мы видим, что метрики являются мощнейшим средством 
сбора и анализа информации. И вместе стем здесь кроется опасность: ни при каких 
условиях нельзя допускать ситуации «метрик ради метрик», когда инструменталь- 
ное средство собирает уйму данных, вычисляет множество чисел и строит десятки 
графиков, но... никто не понимает, как их трактовать. Обратите внимание, что к 
обеим метрикам в таблице 2.6.1 и к только что рассмотренной метрике 
ScheduleSlippage прилагается краткое руководство по их трактовке. И чем сложнее 
и уникальнее метрика, тем более подробное руководство необходимо для её эф- 
фективного применения. 


И, наконец, стоит упомянуть про так называемые «метрики покрытия», т.к. 
они очень часто упоминаются в различной литературе. 





Покрытие (со\уегадеззз) — процентное выражение степени, в которой nc- ' 
‚ следуемый элемент (coverage Ќетзз») затронут соответствующим набором | 














Самыми простыми представителями метрик покрытия можно считать: 


• Метрику покрытия требований (требование считается «покрытым», если на 
него ссылается хотя бы один тест-кейс): 


рСотетей 
- 100%, где 


— метрика покрытия требований, 
— количество требований, покрытых хотя бы одним тест-кейсом, 
— общее количество требований. 


р5йпресСотетаде = 
pRTotal 
р5їтр!еСотетаде 


рСотетеа 
pTotal 


e Метрику плотности покрытия требований (учитывается, сколько тест-кейсов 
ссылается на несколько требований): 
ррепѕііуСотетаде ы ЕЛГЕН М 100%, где 
RPensityCoverage L плотность покрытия требований, 
Т; — количество тест-кейсов, покрывающих ѓе требование, 
TTotal __ общее количество тест-кейсов, 


ВТ _ общее количество требований. 





338 Coverage, Test coverage. Тһе degree, expressed аз а percentage, іо which а specified coverage item has been exercised Бу а 
test suite. [ISTQB Glossary] 

339 Coverage item. An entity or property used as a basis for test coverage, e.g. equivalence partitions or code statements. [ISTQB 
Glossary] 
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e Метрику покрытия классов эквивалентности (анализируется, сколько классов 
эквивалентности затронуто тест-кейсами). 


ЕСотетей 
- 100%, где 


— метрика покрытия классов эквивалентности, 
— количество классов эквивалентности, покрытых хотя бы одним тест-кейсом, 
— общее количество классов эквивалентности. 


Coverage — 
Е — pTotal 
(сСотетаде 


ЕСотетеа 
ЕТО а! 


• Метрику покрытия граничных условий (анализируется, сколько значений из 
группы граничных условий затронуто тест-кейсами). 


вСотетеа 
- 100%, где 


— метрика покрытия граничных условий, 
— количество граничных условий, покрытых хотя бы одним тест-кейсом, 
— общее количество граничных условий. 


Сотетаде — 
В — pTotal 
ВСотетаде 


В Covered 
pTotal 


e Метрики покрытия кода модульными тест-кейсами. Таких метрик очень 
много, но вся их суть сводится к выявлению некоей характеристики кода (ко- 
личество строк, ветвей, путей, условий и т.д.) и определению, какой процент 
представителей этой характеристики покрыт тест-кейсами. 


 Метрик покрытия настолько много, что даже в І5ТОВ-глоссарии дано 


‚ определение полутора десяткам таковых. Вы можете найти эти определе- | 





На этом мы завершаем теоретическое рассмотрение планирования и пере- 
ходим к примеру — учебному тест-плану для нашего приложения «Конвертер фай- 
лов». Напомним, что приложение является предельно простым, потому и тест- 
план будет очень маленьким (однако, обратите внимание, сколь значительную его 
часть будет занимать раздел метрик). 


Пример тест-плана 


Для того чтобы заполнить некоторые части тест-плана, нам придётся сде- 
лать допущения о составе проектной команды и времени, отведённом на разра- 
ботку проекта. Поскольку данный тест-план находится внутри текста книги, у него 
нет таких типичных частей, как заглавная страница, содержание и т.п. Итак. 


Цель 

Корректное автоматическое преобразование содержимого документов кеди- 
ной кодировке с производительностью, значительно превышающей производи- 
тельность человека при выполнении аналогичной задачи. 


Области, подвергаемые тестированию 
(См. соответствующие разделы требований.) 
ПТ-1.*: дымовой тест. 

ПТ-2.*: дымовой тест, тест критического пути. 
ПТ-3.*: тест критического пути. 

БП-1.*: дымовой тест, тест критического пути. 
АК-2.*: дымовой тест, тест критического пути. 
О-4: дымовой тест. 

О-5: дымовой тест. 

ДС-*: дымовой тест, тест критического пути. 
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Области, не подвергаемые тестированию 

СХ-1: приложение разрабатывается как консольное. 

СХ-2, О-1, О-2: приложение разрабатывается на РНР указанной версии. 
АК-1.1: заявленная характеристика находится вблизи нижней границы произ- 
водительности операций, характерных для разрабатываемого приложения. 
О-3: не требует реализации. 

О-6: не требует реализации. 


Тестовая стратегия и подходы 


Общий подход. 
Специфика работы приложения состоит в однократном конфигурировании 


опытным специалистом и дальнейшем использовании конечными пользователями, 
для которых доступна только одна операция — размещение файла в каталоге-при- 
ёмнике. Потому вопросы удобства использования, безопасности и т.п. не исследу- 
ются в процессе тестирования. 


Уровни функционального тестирования: 

Дымовой тест: автоматизированный с использованием командных файлов 
ОС Windows и Linux. 

Тест критического пути: выполняется вручную. 

Расширенный тест не производится, т.к. для данного приложения вероят- 
ность обнаружения дефектов на этом уровне пренебрежимо мала. 


В силу кроссфункциональности команды значительного вклада в повышение 


качества можно ожидать от аудита кода, совмещённого с ручным тестированием по 
методу белого ящика. Автоматизация тестирования кода не будет применяться в 
силу крайне ограниченного времени. 


Критерии 

Приёмочные критерии: успешное прохождение 100 % тест-кейсов уровня ды- 
мового тестирования и 90 % тест-кейсов уровня критического пути (см. мет- 
рику «Успешное прохождение тест-кейсов») при условии устранения 100 % 
дефектов критической и высокой важности (см. метрику «Общее устранение 
дефектов»). Итоговое покрытие требований тест-кейсами (см. метрику «По- 
крытие требований тест-кейсами») должно составлять не менее 80 %. 
Критерии начала тестирования: выход билда. 

Критерии приостановки тестирования: переход к тесту критического пути до- 
пустим только при успешном прохождении 100 % тест-кейсов дымового теста 
(см. метрику «Успешное прохождение тест-кейсов»); тестирование может 
быть приостановлено в случае, если при выполнении не менее 25 % запла- 
нированных тест-кейсов более 50 % из них завершились обнаружением де- 
фекта (см. метрику «Стоп-фактор»). 

Критерии возобновления тестирования: исправление более 50 % обнаружен- 
ных на предыдущей итерации дефектов (см. метрику «Текущее устранение 
дефектов»). 

Критерии завершения тестирования: выполнение более 80 % запланирован- 
ных на итерацию тест-кейсов (см. метрику «Выполнение тест-кейсов»). 


Ресурсы 

Программные ресурсы: четыре виртуальных машины (две с ОС Windows 7 
Ent x64, две с ОС Linux Ubuntu 14 LTS x64), две копии РНР Storm 8. 
Аппаратные ресурсы: две стандартных рабочих станции (8GB RAM, 17 ЗӘН2). 
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• Человеческие ресурсы: 

о Старший разработчик с опытом тестирования (100%-я занятость на 
всём протяжении проекта). Роли на проекте: лидер команды, старший 
разработчик. 

о Тестировщик со знанием РНР (100%-я занятость на всём протяжении 
проекта). Роль на проекте: тестировщик. 

e Временные ресурсы: одна рабочая неделя (40 часов). 
• Финансовые ресурсы: согласно утверждённому бюджету. Дополнительные 
финансовые ресурсы не требуются. 


Расписание 

• 25.05 — формирование требований. 

• 26.05 — разработка тест-кейсов и скриптов для автоматизированного тести- 
рования. 

e 27.05-28.05 — основная фаза тестирования (выполнение тест-кейсов, Hann- 
сание отчётов о дефектах). 

• 29.05 — завершение тестирования и подведение итогов. 


Роли и ответственность 

• Старший разработчик: участие в формировании требований, участие в 
аудите кода. 

• Тестировщик: формирование тестовой документации, реализация тестиро- 
вания, участие в аудите кода. 


Оценка рисков 

• Персонал (вероятность низкая): в случае нетрудоспособности какого-либо из 
участников команды можно обратиться к представителям проекта «Катало- 
гизатор» для предоставления временной замены (договорённость с мене- 
джером «Каталогизатора» Джоном Смитом достигнута). 

e Время (вероятность высокая): заказчиком обозначен крайний срок сдачи 
01.06, потому время является критическим ресурсом. Рекомендуется прило- 
жить максимум усилий к тому, чтобы фактически завершить проект 28.05 с 
тем, чтобы один день (29.05) остался в запасе. 

e Иные риски: иных специфических рисков не выявлено. 


Документация 

• Требования. Ответственный — тестировщик, дата готовности 25.05. 

e Тест-кейсы и отчёты о дефектах. Ответственный — тестировщик, период co- 
здания 26.05-28.05. 

• Отчёт о результатах тестирования. Ответственный — тестировщик, дата го- 
товности 29.05. 


Метрики 
• Успешное прохождение тест-кейсов: 
Success 
TSP = 1 . 100%, где 


— тТоёа1 


Т5Р — процентный показатель успешного прохождения тест-кейсов, 
Т 5655 — количество успешно выполненных тест-кейсов, 
ТТо — общее количество выполненных тест-кейсов. 
Минимальные границы значений: 

о Начальная фаза проекта: 10%. 

о Основная фаза проекта: 40%. 

о Финальная фаза проекта: 80%. 
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• Общее устранение дефектов: 


ЕТР р 

— ете! _, 0, 

Dievel — pFound 100%, где 
Level 





ры — процентный показатель устранения дефектов уровня важности Level за время 


существования проекта 

DELSed — количество устранённых за время существования проекта дефектов уровня 
важности Level, 

рёоипӣ — количество обнаруженных за время существования проекта дефектов уровня 
важности Level. 

Минимальные границы значений: 




















Важность дефекта 
Низкая Средняя Высокая Критическая 
baza Начальная 10% 40% 50% 80% 
проекта Основная 15% 50% 75% 90% 
Финальная 20% 60% 100% 100% 




















e Текущее устранение дефектов: 
С1о5еа 
Ба = Ре. 100%, где 
Level 





DESP — процентный показатель устранения в текущем билде дефектов уровня важности 


Level, обнаруженных в предыдущем билде, 
12615е4 — количество устранённых в текущем билде дефектов уровня важности Level, 
р[ била — количество обнаруженных в предыдущем билде дефектов уровня важности Level. 
Минимальные границы значений: 






































Важность дефекта 
Низкая Средняя Высокая Критическая 
база Начальная 60% 60% 60% 60% 
проекта Основная 65% 70% 85% 90% 
Финальная 70% 80% 95% 100% 
• Стоп-фактор: 
_ (Yes, ТЕ > 25% && Т < 50% 
=f No, ТЕ < 25% || TSP > 50% °S 


$ — решение о приостановке тестирования, 
ТЕ — текущее значение метрики Т“, 
TSP — текущее значение метрики Т°5?. 


e Выполнение тест-кейсов: 


тЕхесшеа 
ТЕ = . 100%, где 


`"тРЇатпей 
ТЕ — процентный показатель выполнения тест-кейсов, 
Executed количество выполненных тест-кейсов, 
ТР!атте4 __ количество тест-кейсов, запланированных к выполнению. 
Уровни (границы): 

о Минимальный уровень: 80 %. 

о Желаемый уровень: 95-100 %. 


• Покрытие требований тест-кейсами: 
Covered 
RE = - 100%, где 


Това. 
ВС — процентный показатель покрытия требования тест-кейсами, 
ВС07ете1 — количество покрытых тест-кейсами требований, 
ВТО — общее количество требований. 
Минимальные границы значений: 

о Начальная фаза проекта: 40 %. 

о Основная фаза проекта: 60 %. 

о Финальная фаза проекта: 80 % (рекомендуется 90 % и более). 
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Задание 2.6.а: поищите в Интернет более развёрнутые примеры тест- 
‚ планов. Они периодически появляются, но и столь же быстро удаляются, | 
т.к. настоящие (не учебные) тест-планы, как правило, являются конфиден- | 





иальной информацией. 


На этом мы завершаем обсуждение планирования и переходим к отчётности, 
которая завершает цикл тестирования. 


Отчёт о результатах тестирования 





Отчёт о результатах тестирования (test progress геропз^о, test summary 
report) — документ, обобщающий результаты работ по тестированию и | 





К низкоуровневым задачам отчётности в тестировании относятся: 

e оценка объёма и качества выполненных работ; 

e сравнение текущего прогресса с тест-планом (в том числе с помощью aHa- 
лиза значений метрик); 

e описание имеющихся сложностей и формирование рекомендаций по их 
устранению; 

e предоставление лицам, заинтересованным в проекте, полной и объективной 
информации о текущем состоянии качества проекта, выраженной в конкрет- 
ных фактах и числах. 


Как и любой другой документ, отчёт о результатах тестирования может быть 
качественным или обладать недостатками. Качественный отчёт о результатах те- 
стирования обладает многими свойствами качественных требований“, а также 
расширяет их набор следующими пунктами: 

e Информативность (в идеале после прочтения отчёта не должно оставаться 
никаких открытых вопросов о том, что происходит с проектом в контексте ка- 
чества). 

• Точность и объективность (ни при каких условиях в отчёте не допускается 
искажение фактов, а личные мнения должны быть подкреплены твёрдыми 
обоснованиями). 


Отчёт о результатах тестирования создаётся по заранее оговорённому рас- 
писанию (зависящему от модели управления проектом) при участии большинства 
представителей проектной команды, задействованных в обеспечении качества. 
Большое количество фактических данных для отчёта может быть легко извлечено 
в удобной форме из системы управления проектом. Ответственным за создание 
отчёта, как правило, является ведущий тестировщик («тест-лид»). При необходи- 
мости отчёт может обсуждаться на небольших собраниях. 

Отчёт о результатах тестирования в первую очередь нужен следующим ли- 
цам: 

• менеджеру проекта — как источник информации о текущей ситуации и ос- 
нова для принятия управленческих решений; 

e руководителю команды разработчиков («дев-лиду») — как дополнительный 
объективный взгляд на происходящее на проекте; 





340 Test progress report. А document summarizing testing activities and results, produced at regular intervals, to report progress ої 
testing activities against a baseline (such as the original test plan) and to communicate risks and alternatives requiring a decision 
to management. [ISTQB Glossary] 

341 Test summary report. A document summarizing testing activities and results. It also contains an evaluation of the corresponding 
test items against exit criteria. [ISTQB Glossary] 
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e руководителю команды тестировщиков («тест-лиду») — как способ структу- 
рировать собственные мысли и собрать необходимый материал для обра- 
щения к менеджеру проекта по насущным вопросам, если в этом есть необ- 
ходимость; 

e заказчику — как наиболее объективный источник информации о том, что про- 
исходит на проекте, за который он платит свои деньги. 


В общем случае отчёт о результатах тестирования включает следующие раз- 
делы (примеры их наполнения будут показаны далее, потому здесь — только пере- 
числение). 









Важно! Если по поводу тест-плана в сообществе тестировщиков есть 60- ' 
‚ лее-менее устоявшееся мнение, то формы отчётов о результатах тести- 
рования исчисляются десятками (особенно, если отчёт привязан к некото- ' 
рому отдельному виду тестирования). Здесь приведён наиболее универ- | 
 сальный вариант, который может быть адаптирован под конкретные | 





• Краткое описание (зиттагу). В предельно краткой форме отражает основ- 
ные достижения, проблемы, выводы и рекомендации. В идеальном случае 
прочтения краткого описания может быть достаточно для формирования 
полноценного представления о происходящем, что избавит от необходимо- 
сти читать весь отчёт (это важно, т.к. отчёт о результатах тестирования мо- 
жет попадать в руки очень занятым людям). 








ажно! Различайте краткое описание отчёта о результатах тестиро- 
вания и краткое описание отчёта о дефекте“?! При одинаковом | 
' названии они создаются по разным принципам и содержат разную | 

нформацию! 





• Команда тестировщиков (test team). Список участников проектной команды, 
задействованных в обеспечении качества, с указанием их должностей и ро- 
лей в подотчётный период. 

• Описание процесса тестирования (testing process description). Последова- 
тельное описание того, какие работы были выполнены за подотчётный пе- 
риод. 

e Расписание (timetable). Детализированное расписание работы команды TE- 
стировщиков и/или личные расписания участников команды. 

e Статистика по новым дефектам (new defects statistics). Таблица, в которой 
представлены данные по обнаруженным за подотчётный период дефектам 
(с классификацией по стадии жизненного цикла и важности). 

e Список новых дефектов (new defects list). Список обнаруженных за подот- 
чётный период дефектов с их краткими описаниями и важностью. 

e Статистика по всем дефектам (overall defects statistics). Таблица, в которой 
представлены данные по обнаруженным за всё время существования про- 
екта дефектам (с классификацией по стадии жизненного цикла и важности). 
Как правило, в этот же раздел добавляется график, отражающий такие ста- 
тистические данные. 

e Рекомендации (recommendations). Обоснованные выводы и рекомендации 
по принятию тех или иных управленческих решений (изменению тест-плана, 
запросу или освобождению ресурсов и т.д.). Здесь этой информации можно 
отвести больше места, чем в кратком описании (ѕиттагу), сделав акцент 
именно на том, что и почему рекомендуется сделать в имеющейся ситуации. 
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Приложения (appendixes). Фактические данные (как правило, значения MeT- 
рик и графическое представление их изменения во времени). 


Логика построения отчёта о результатах тестирования 
Для того чтобы отчёт о результатах тестирования был действительно полез- 


ным, при его создании следует постоянно помнить об универсальной логике отчёт- 
ности (см. рисунок 2.6.6), особенно актуальной для таких разделов отчёта о резуль- 


татах 


тестирования, как 


(recommendations): 
Выводы строятся на основе целей (которые были отражены в плане). 
Выводы дополняются рекомендациями. 

Как выводы, так и рекомендации строго обосновываются. 
Обоснование опирается на объективные факты. 


На основе 
целей s4 
Выводы 


краткое описание 


(зиттагу) и рекомендации 


Рекомендации 


Обоснование 


Фактический материал 


Рисунок 2.6.6 — Универсальная логика отчётности 


Выводы должны быть: 
Краткими. Сравните: 





Плохо 


Хорошо 





1.17. Как показал глубокий анализ протоко- 
лов о выполнении тестирования, можно 
сделать достаточно уверенные выводы о 
том, что основная часть функций, отмечен- 
ных заказчиком как наиболее важные, функ- 
ционирует в рамках допустимых отклоне- 
ний от согласованных на последнем обсуж- 
дении с заказчиком метрик качества. 








1.11. Базовая функциональность полно- 
стью работоспособна (см. 2.1-2.2). 


1.23. Существуют некритические проблемы 
с детализацией сообщений в файле жур- 
нала (см. 2.3-2.4). 


1.28. Тестирование приложения под ОС 
Linux не удалось провести из-за недоступ- 
ности сервера SR-85 (см. 2.5). 





Информативными. Сравните: 





Плохо 


Хорошо 





1.8. Результаты обработки файлов с множе- 
ственными кодировками, представленными 
в сопоставимых пропорциях, оставляют же- 
лать лучшего. 

1.9. Приложение не запускается при некото- 
рых значениях параметров командной 
строки. 


1.10. Непонятно, что происходит с анализом 
изменения содержимого входного каталога. 








1.8. Обнаружены серьёзные проблемы с 
библиотекой распознавания кодировок (см. 
ВВ 834). 


1.9. Нарушена функциональность анализа 
параметров командной строки (см. ВВ 745, 
ВВ 877, BR 878). 


1.10. Выявлена нестабильность в работе 
модуля «Сканер», проводятся дополни- 
тельные исследования. 








Тестирование программного обеспечения. Базовый курс. 


© ЕРАМ Systems, 2015-2021 Стр: 219/298 








Тест-план и отчёт о результатах тестирования 





Полезными для читающего отчёт. Сравните: 





Плохо 


Хорошо 





1.18. Некоторые тесты прошли на удивле- 
ние хорошо. 


1.19. В процессе тестирования мы не испы- 
тывали сложности с настройкой среды ав- 
томатизации. 


1.20. По сравнению с результатами, кото- 
рые были получены вчера, ситуация не- 
много улучшилась. 


1.21. С качеством по-прежнему есть некото- 
рые проблемы. 


1.22. Часть команды была в отпуске, но мы 
всё равно справились. 








Представленного в колонке «Плохо» 
просто не должно быть в отчёте! 





Рекомендации должны быть: 


Краткими. Да, мы снова говорим о краткости, т.к. её отсутствием страдает 
слишком большое количество документов. Сравните: 





Плохо 


Хорошо 





2.98. Мы рекомендуем рассмотреть воз- 
можные варианты исправления данной си- 
туации в контексте поиска оптимального 
решения при условии минимизации усилий 
разработчиков и максимального повыше- 
ния соответствия приложения заявленным 
критериям качества, а именно: исследо- 
вать возможность замены некоторых биб- 
лиотек их более качественными анало- 
гами. 








2.98. Необходимо изменить способ опреде- 
ления кодировки текста в документе. Воз- 
можные решения: 

® [сложно, надёжно, но очень долго] напи- 
сать собственное решение; 

• [требует дополнительного исследования и 
согласования] заменить проблемную биб- 
лиотеку «сїїк п г соаіпод» аналогом (воз- 
можно, коммерческим). 





Реально выполнимыми. Сравните: 





Плохо 


Хорошо 





2.107. Использовать механизм обработки 
слов, аналогичный используемому в 
Google. 


2.304. Не загружать в оперативную память 
информацию о файлах во входном ката- 
логе. 


2.402. Полностью переписать проект без 
использования внешних библиотек. 








2.107. Реализовать алгоритм приведения 
слов русского языка к именительному па- 
дежу (см. описание по ссылке ...) 


2.304. Увеличить размер доступной скрипту 
оперативной памяти на 40-50% (в идеале — 
до 512 МБ). 


2.402. Заменить собственными решениями 
функции анализа содержимого каталога и 
параметров файлов библиотеки 
«ск п г Яѕїіт». 
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• Дающими как понимание того, что надо сделать, так и некоторое простран- 
ство для принятия собственных решений. Сравните: 








Плохо Хорошо 
2.212. Рекомендуем поискать варианты ре- | 2.212. Возможные варианты решения: 
шения этого вопроса. а)... 
б) [рекомендуем!| ... 


2.245. Использовать только дисковую сор- в)... 
тировку. 

2.245. Добавить функциональность опреде- 
ления оптимального метода сортировки в 
зависимости от количества доступной опе- 


рати вной памяти. 


2.278. Исключить возможность передачи 
некорректных имён файла журнала через 
параметр командной строки. 


2.278. Добавить фильтрацию имени файла 
журнала, получаемого через параметр ко- 
мандной строки, с помощью регулярного 
выражения. 














Обоснование выводов и рекомендаций — промежуточное звено между пре- 
дельно сжатыми результатами анализа и огромным количеством фактических дан- 
ных. Оно даёт ответы на вопросы наподобие: 

• «Почему мы так считаем?» 
• «Неужели это так?!» 
• «Где взять дополнительные данные?» 








Сравните: 

Плохо Хорошо 
4.107. Покрытие требований тест-кейсами | 4.107. Покрытие требований тест-кейсами 
достаточно. вышло на достаточный уровень (значение 


ВС составило 63 % при заявленном мини- 


4.304. Необходимо больше усилий напра- муме 60 % для текущей стадии проекта). 


вить на регрессионное тестирование. 
4.304. Необходимо больше усилий напра- 
вить на регрессионное тестирование, т.к. 
две предыдущих итерации выявили 21 де- 
фект высокой важности (см. список в 5.43) в 
функциональности, в которой ранее не об- 
наруживалось проблем. 


4.402. От сокращения сроков разработки 
стоит отказаться. 


4.402. От сокращения сроков разработки 
стоит отказаться, т.к. текущее опережение 
графика на 30 человеко-часов может быть 
легко поглощено на стадии реализации тре- 
бований R84.* и В89.*. 














Фактический материал содержит самые разнообразные данные, получен- 
ные в процессе тестирования. Сюда могут относиться отчёты о дефектах, журналы 
работы средств автоматизации, созданные различными приложениями наборы 
файлов и т.д. Как правило, к отчёту о результатах тестирования прилагаются лишь 
сокращённые агрегированные выборки подобных данных (если это возможно), а 
также приводятся ссылки на соответствующие документы, разделы системы управ- 
ления проектом, пути в хранилище данных ит.д. 


На этом мы завершаем теоретическое рассмотрение отчётности и перехо- 
дим к примеру — учебному отчёту о результатах тестирования нашего приложения 
«Конвертер файлов»°?. Напомним, что приложение является предельно простым, 
потому и отчёт о результатах тестирования будет очень маленьким. 
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Пример отчёта о результатах тестирования 


Для того, чтобы заполнить некоторые части отчёта, нам придётся сделать 
допущения о текущем моменте развития проекта и сложившейся ситуации с каче- 
ством. Поскольку данный отчёт находится внутри текста книги, у него нет таких ти- 
пичных частей, как обложка, содержание ит.п. 

Итак. 


Краткое описание. За период 26-28 мая было выпущено четыре билда, на 
последнем из которых успешно прошло 100 % тест-кейсов дымового тестирования 
и 76 % тест-кейсов тестирования критического пути. 98 % требований высокой важ- 
ности реализовано корректно. Метрики качества находятся в зелёной зоне, потому 
есть все основания рассчитывать на завершение проекта в срок (на текущий мо- 
мент реальный прогресс в точности соответствует плану). На следующую итерацию 
(29 мая) запланировано выполнение оставшихся низкоприоритетных тест-кейсов. 


Команда тестировщиков. 























Имя Должность Роль 
Джо Блэк Тестировщик Ответственный за обеспече- 
ние качества 
Джим Уайт Старший разработчик Ответственный за парное те- 
стирование и аудит кода 





Описание процесса тестирования. Каждый из четырёх выпущенных за под- 
отчётный период билдов (3—6) был протестирован под ОС Windows 7 Ent x64 и ОС 
Linux Ubuntu 14 LTS x64 в среде исполнения РНР 5.6.0. Дымовое тестирование (см. 
http://projects/FC/Testing/SmokeTest) выполнялось с использованием автоматиза- 
ции на основе командных файлов (см. \\PROJECTS\FO\Testing\Aut\Scripts). Тести- 
рование критического пути (см. http://projects/FC/Testing/CriticalPathTest) выполня- 
лось вручную. Регрессионное тестирование показало высокую стабильность функ- 
циональности (обнаружен только один дефект с важностью «средняя»), а повтор- 
ное тестирование показало ощутимый прирост качества (исправлено 83 % обнару- 
женных ранее дефектов). 









































Расписание. 
Имя Дата Деятельность Продолжительность, ч 
Джо Блэк 27.05.2015 Разработка тест-кейсов 2 
Джо Блэк 27.05.2015 Парное тестирование 2 
Джо Блэк 27.05.2015 Автоматизация дымового тестирова- 1 
ния 
Джо Блэк 27.05.2015 Написание отчётов о дефектах 2 
Джим Уайт 27.05.2015 Аудит кода 1 
Джим Уайт 27.05.2015 Парное тестирование 2 
Джо Блэк 28.05.2015 Разработка тест-кейсов 3 
Джо Блэк 28.05.2015 Парное тестирование 1 
Джо Блэк 28.05.2015 Написание отчётов о дефектах 2 
Джо Блэк 28.05.2015 Написание отчёта о результатах те- 1 
стирования 
Джим Уайт 28.05.2015 Аудит кода 1 
Джим Уайт 28.05.2015 Парное тестирование 1 
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Статистика по новым дефектам. 
























































Важность 
Статус Количество Низкая Средняя Высокая Критическая 
Найдено 23 2 12 7 2 
Исправлено 17 0 9 6 2 
Проверено 13 0 5 6 2 
Открыто за- 1 0 0 1 0 
ново 
Отклонено 3 0 2 1 0 
Список новых дефектов. 
Идентификатор Важность Описание 
ВВ 21 Высокая Приложение не различает файлы и символические 
ссылки на файлы. 
ВА 22 Критическая Приложение игнорирует файлы .та во входном ката- 
логе. 








И так далее — описание всех 23 найденных дефектов. 





Статистика по всем дефектам. 









































Важность 
Статус Количество Низкая Средняя Высокая Критическая 

Найдено 34 5 18 8 3 
Исправлено 25 3 12 7 3 
Проверено 17 0 7 7 3 
Открыто 3a- 1 0 0 1 0 
ново 

Отклонено 4 0 3 1 0 





Статистика по всем дефектам 


1 2 


=== Найдено === Закрыто 


З 4 


5 


Всего найдено === Всего закрыто 


26.05.2015 26.05.2015 27.05.2015 27.05.2015 28.05.2015 28.05.2015 


Рекомендации. В настоящий момент никаких изменений не требуется. 
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Приложение. График изменения значений метрик. 


Метрики 


200 
180 
160 
140 
120 


100 
80 == == - 
60 >< > == 


40 — 
20 


0 УФ— к. 
26.05.2015 26.05.2015 27.05.2015 27.05.2015 28.05.2015 28.05.2015 
1 2 3 4 5 6 
= Tsp — Ор Оїср === С) шшш» ГО ә Rc 





( ‚ Задание 2.6.6: поищите в Интернете более развёрнутые примеры отчётов 
| ‚ о результатах тестирования. Они периодически появляются, но и столь же | 
‚ быстро удаляются, т.к. настоящие (не учебные) отчёты, как правило, AB- | 
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2.6.3. Оценка трудозатрат 


В завершение данной главы мы снова возвращаемся к планированию, но уже 
куда более простому — к оценке трудозатрат. 





‚ Трудозатраты (man-hours) — количество рабочего времени, необходи- | 
мого для выполнения работы (выражается в человеко-часах). 





Каждый раз, когда вы получаете задание или выдаёте кому-то задание, явно 

или неявно возникают вопросы наподобие следующих: 

e Как много времени понадобится на выполнение работы? 

e Когда всё будет готово? 

• Можно ли гарантированно выполнить работу к такому-то сроку? 

e Каковы наиболее оптимистичный и пессимистичный прогнозы по времени? 
Рассмотрим несколько соображений относительно того, как производится 
оценка трудозатрат. 


Любая оценка лучше её отсутствия. Даже если область предстоящей ра- 
боты для вас совершенно нова, даже если вы ошибётесь в своей оценке на поря- 
док, вы как минимум получите опыт, который сможете использовать в будущем при 
возникновении подобного рода задач. 


Оптимизм губителен. Как правило, люди склонны недооценивать сложность 
незнакомых задач, что приводит к занижению оценки трудозатрат. 

Но даже при достаточно точном определении самих трудозатрат люди без 
опыта выполнения оценки склонны рассматривать предстоящую работу как некую 
изолированную деятельность, забывая о том, что на протяжении любого рабочего 
дня «чистую производительность труда» будут снижать такие факторы, как пере- 
писка по почте, участие в собраниях и обсуждениях, решение сопутствующих тех- 
нических вопросов, изучение документации и обдумывание сложных частей задачи, 
форс-мажорные обстоятельства (неотложные дела, проблемы с техникой и т.д.). 

Таким образом, обязательно стоит учитывать, что в реальности вы сможете 
заниматься поставленной задачей не 100 % рабочего времени, а меньше 
(насколько меньше — зависит от конкретной ситуации, в среднем принято считать, 
что на поставленную задачу из каждых восьми рабочих часов вы сможете потратить 
не более шести). Учитывая этот факт, стоит сделать соответствующие поправки в 
оценке общего времени, которое понадобится на выполнение работы (а именно оно 
чаще всего интересует постановщика задачи). 


Оценка должна быть аргументирована. Это не значит, что вы всегда 
должны пускаться в подробные пояснения, но вы должны быть готовы объяснить, 
почему вы считаете, что та или иная работа займёт именно столько времени. Во- 
первых, продумывая эти аргументы, вы получаете дополнительную возможность 
лучше оценить предстоящую работу и скорректировать оценку. Во-вторых, если 
ваша оценка не соответствует ожиданиям постановщика задачи, вы сможете отсто- 
ять свою точку зрения. 





342 Мап-һоиг. А unit for measuring work іп industry, equal їо the work done Бу опе man іп опе hour. [http://dictionary.refer- 
ence.com/browse/man-hour] 
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Простой способ научиться оценивать — оценивать. В специализирован- 
ной литературе (см. ниже небольшой список) приводится множество технологий, но 
первична сама привычка выполнять оценку предстоящей работы. В процессе вы- 
работки этой привычки вы естественным образом встретитесь с большинством ти- 
пичных проблем и через некоторое время научитесь делать соответствующие по- 
правки в оценке, даже не задумываясь. 

Что оценивать? Что угодно. Сколько времени у вас уйдёт на прочтение новой 
книги. За сколько времени вы доедете домой новым маршрутом. За сколько вре- 
мени вы напишете курсовую или дипломную работу. И так далее. Не важно, что 
именно вы оцениваете, важно, что вы повторяете это раз за разом, учитывая накап- 
ливающийся опыт. 





Если вас заинтересовал профессиональный подход к формированию | 
‚ оценки трудозатрат, рекомендуется ознакомиться со следующими источ- 
никами: | 
‚ ® «The Mythical Мап Month», Frederick Brooks. 

ө «Controlling Software Projects», Tom De Marco. 





Алгоритм обучения формированию оценки: 

e Сформируйте оценку. Ранее уже было отмечено, что нет ничего страшного в 
том, что полученное значение может оказаться очень далёким от реально- 
сти. Для начала оно просто должно быть. 

e Запишите полученную оценку. Обязательно именно запишите. Это за- 
страхует вас как минимум от двух рисков: забыть полученное значение (осо- 
бенно, если работа заняла много времени), соврать себе в стиле «ну, я как- 
то примерно так и думал». 

• Выполните работу. В отдельных случаях люди склонны подстраиваться под 
заранее сформированную оценку, ускоряя или замедляя выполнение ра- 
боты, — это тоже полезный навык, но сейчас такое поведение будет мешать. 
Однако если вы будете тренироваться на десятках и сотнях различных за- 
дач, вы физически не сможете «подстроиться» под каждую из них и начнёте 
получать реальные результаты. 

e Сверьте реальные результаты с ранее сформированной оценкой. 

• Учтите ошибки при формировании новых оценок. На этом этапе очень по- 
лезно не просто отметить отклонение, а подумать, что привело к его появле- 
нию. 

• Повторяйте этот алгоритм как можно чаще для самых различных областей 
жизни. Сейчас цена ваших ошибок крайне мала, а наработанный опыт от 
этого становится ничуть не менее ценным. 


Полезные идеи по формированию оценки трудозатрат: 

• Добавляйте небольшой «буфер» (по времени, бюджету или иным критиче- 
ским ресурсам) на непредвиденные обстоятельства. Чем более дальний про- 
гноз вы строите, тем большим может быть этот «буфер» — от 5-10 % до 30- 
40 %. Но ни в коем случае не стоит осознанно завышать оценку в разы. 

• Выясните свой «коэффициент искажения»: большинство людей в силу осо- 
бенности своего мышления склонны постоянно или занижать, или завышать 
оценку. Многократно формируя оценку трудозатрат и сравнивая её впослед- 
ствии с реальностью, вы можете заметить определённую закономерность, 
которую вполне можно выразить числом. Например, может оказаться, что вы 
склонны занижать оценку в 1.3 раза. Попробуйте в следующий раз внести 
соответствующую поправку. 
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• Принимайте во внимание не зависящие от вас обстоятельства. Например, 
вы точно уверены, что выполните тестирование очередного билда за М че- 
ловеко-часов, вы учли все отвлекающие факторы и т.д. и решили, что точно 
закончите к такой-то дате. А потом в реальности выпуск билда задержива- 
ется на два дня, и ваш прогноз по моменту завершения работы оказывается 
нереалистичным. 

e Задумывайтесь заранее о необходимых ресурсах. Так, например, необходи- 
мую инфраструктуру можно (и нужно!) подготовить (или заказать) заранее, 
т.к. на подобные вспомогательные задачи может быть потрачено много вре- 
мени, к тому же основная работа часто не может быть начата, пока не будут 
завершены все приготовления. 

• Ищите способы организовать параллельное выполнение задач. Даже если 
вы работаете один, всё равно какие-то задачи можно и нужно выполнять па- 
раллельно (например, уточнение тест-плана, пока происходит разворачива- 
ние виртуальных машин). В случае если работа выполняется несколькими 
людьми, распараллеливание работы можно считать жизненной необходимо- 
стью. 

• Периодически сверяйтесь с планом, вносите корректировки в оценку и уве- 
домляйте заинтересованных лиц о внесённых изменениях заблаговременно. 
Например, вы поняли (как в упомянутом выше примере с задержкой билда), 
что завершите работу как минимум на два дня позже. Если вы оповестите 
проектную команду немедленно, у ваших коллег появляется шанс скорректи- 
ровать свои собственные планы. Если же вы в «час икс» преподнесёте сюр- 
приз о сдвигах срока на два дня, вы создадите коллегам объективную про- 
блему. 

• Используйте инструментальные средства — от электронных календарей до 
возможностей вашей системы управления проектом: это позволит вам как 
минимум не держать в памяти кучу мелочей, а как максимум — повысит точ- 
ность формируемой оценки. 


Оценка с использованием структурной декомпозиции 





С другими техниками формирования оценки вы можете ознакомиться в 
‚ следующей литературе: | 
| » «Essential Scrum», Kenneth Rubin. 

«Agile Estimating and Planning», Mike Cohn. 

«Extreme programming explained: Embrace change», Kent Beck. 

PMBOK («Project Management Body of Knowledge»). | 
Краткий перечень основных техник с пояснениями можно посмотреть в. 
статье «Software Estimation Techniques — Соттоп Test Estimation Tech- 





Структурная декомпозиция (work breakdown structure, WBS) — иерар- 
‚ хическая декомпозиция объёмных задач на всё более и более малые под- | 
задачи с целью упрощения оценки, планирования и мониторинга выпол- ' 
нения работы. | 









343 «Software Estimation Techniques - Соттоп Test Estimation Techniques used іп SDLC» [http://www.softwaretest- 


ingclass.com/software-estimation-techniques/] 

344 The WBS is а deliverable-oriented hierarchical decomposition of the work to be executed by the project team, to accomplish the 
project objectives and create the required deliverables. The WBS organizes and defines the total scope of the project. The WBS 
subdivides the project work into smaller, more manageable pieces of work, with each descending level of the WBS representing 
an increasingly detailed definition of the project work. The planned work contained within the lowest-level WBS components, 
which are called work packages, can be scheduled, cost estimated, monitored, and controlled. [PMBOK, 3" edition] 
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В процессе выполнения структурной декомпозиции большие задачи делятся 
на всё более и более мелкие подзадачи, что позволяет нам: 

e описать весь объём работ с точностью, достаточной для чёткого понимания 
сути задач, формирования достаточно точной оценки трудозатрат и выра- 
ботки показателей достижения результатов; 

e определить весь объём трудозатрат как сумму трудозатрат по отдельным за- 
дачам (с учётом необходимых поправок); 

e от интуитивного представления перейти к конкретному перечню отдельных 
действий, что упрощает построение плана, принятие решений о распаралле- 
ливании работ и т.д. 


Сейчас мы рассмотрим применение структурной декомпозиции в сочетании 
с упрощённым взглядом на оценку трудозатрат на основе требований и тест-кей- 


СОВ. 





‚ С подробной теорией по данному вопросу можно ознакомиться в следую- 
щих статьях: | 
‚ ® «Test Effort Estimation Using Use Case Points», Suresh Мадеѕмагап. 





Если абстрагироваться от научного подхода и формул, то суть такой оценки 
сводится к следующим шагам: 

• декомпозиции требований до уровня, на котором появляется возможность 
создания качественных чек-листов; 

e декомпозиции задач по тестированию каждого пункта чек-листа до уровня 
«тестировщицких действий» (создание тест-кейсов, выполнение тест-кейсов, 
создание отчётов о дефектах и т.д.); 

• выполнению оценки с учётом собственной производительности. 


Рассмотрим этот подход на примере тестирования требования ДС-2.45°: 
«При указании неверного значения любого из параметров командной строки прило- 
жение должно завершить работу, выдав сообщение об использовании (ДС-3.1), а 
также сообщив имя неверно указанного параметра, его значение и суть ошибки (см. 
ДС-3.2)». 


Это требование само по себе является низкоуровневым и почти не требует 
декомпозиции, но чтобы проиллюстрировать суть подхода, проведём разделение 
требования на составляющие: 

e Если все три параметра командной строки указаны верно, сообщение об 
ошибке не выдаётся. 

• Если указано неверно от одного до трёх параметров, то выдаётся сообщение 
об использовании, имя (или имена) неверно указанного параметра и невер- 
ное значение, а также сообщение об ошибке: 

о Если неверно указан SOURCE_DIR или ОЕЅТІМАТІОМ№ ОІВ: «Directory 
пої exists ог inaccessible». 

о Если ОЕЅТІМАТІОМ ВІВ находится в SOURCE_DIR: «Destination dir 
тау пої reside within source dir tree». 

о Если неверно указан LOG_FILE_NAME: «Wrong file name or inaccessi- 
ble path». 





345 «Test Effort Estimation Using Use Case Points», Suresh Nageswaran [http://citeseerx.ist.psu.edu/viewdoc/down- 
load?doi=10.1.1.597.6800&rep=rep1&type=pdf] 
346 «Test Case Point Analysis», Nirav Patel [http://www.stickyminds.com/sites/default/files/article/file/2013/XUS373692file1_0.pdf] 





Тестирование программного обеспечения. Базовый курс. © ЕРАМ Systems, 2015-2021 Стр: 228/298 


Оценка трудозатрат 





Создадим чек-лист и здесь же пропишем примерное количество тест-кейсов 
на каждый пункт из предположения, что мы будем проводить достаточно глубокое 
тестирование этого требования: 

e Все параметры корректные {1 тест-кейс}. 

• Несуществующий/некорректный путь для: 

о ЗОЧАСЕ ГВ {3 тест-кейса}; 
о ОЕЗТМАТЮМ_ ОІВ {3 тест-кейса}. 

e Недопустимое имя файла LOG_FILE_NAME {3 тест-кейса}. 

e Значения ЅОЦВСЕ DIR и ОЕЗТИМАТЮМ_О1В являются корректными име- 
нами существующих каталогов, но ОЕЅТІМАТІОМ ВІВ находится внутри 
SOURCE_DIR {3 тест-кейса}. 

• Недопустимые/несуществующие имена объектов ФС указаны в более чем 
одном параметре {5 тест-кейсов). 

e Значения SOURCE_DIR и ОЕЅТІМАТІОМ ВІА не являются корректными/су- 
ществующими именами каталогов, и при этом ОЕЅТІМАТІОМ БІН находится 
внутри SOURCE_DIR {3 тест-кейса}. 


У нас получилось примерно 22 тест-кейса. Также давайте для большей пока- 
зательности примера предположим, что часть тест-кейсов (например, 10) уже была 
создана ранее. 

Теперь сведём полученные данные в таблицу 2.6.а, где также отразим коли- 
чество проходов. Этот показатель появляется из соображения, что некоторые тест- 
кейсы будут находить дефекты, что потребует повторного выполнения тест-кейса 
для верификации исправления дефекта; в некоторых случаях дефекты будут от- 
крыты заново, что потребует повторной верификации. Это относится лишь к части 
тест-кейсов, потому количество проходов может быть дробным, чтобы оценка была 
более точной. 

Количество проходов для тестирования новой функциональности в общем 
случае можно грубо оценивать так: 

e Простая функциональность: 1-1.5 (не все тесты повторяются). 
• Функциональность средней сложности: 2. 
• Сложная функциональность: 3-5. 


Таблица 2.6.а — Оценка количества создаваемых и выполняемых тест-кейсов 
































Создание Выполнение 
Количество 12 22 
Повторения (проходы) 1 1.2 
Общее количество 12 26.4 
Время на один тест-кейс 
Итоговое время 





Осталось заполнить ячейки со значениями времени, необходимого на разра- 
ботку и выполнение одного тест-кейса. К сожалению, не существует никаких маги- 
ческих способов выяснения этих параметров — только накопленный опыт о вашей 
собственной производительности, на которую среди прочего влияют следующие 
факторы (по каждому из них можно вводить коэффициенты, уточняющие оценку): 

e ваш профессионализм и опыт; 
сложность и объёмность тест-кейсов; 
производительность тестируемого приложения и тестового окружения; 
вид тестирования; 
наличие и удобство средств автоматизации; 
стадия разработки проекта. 
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Тем не менее существует простой способ получения интегральной оценки 
вашей собственной производительности, при котором влиянием этих факторов 
можно пренебречь: нужно измерять свою производительность на протяжении дли- 
тельного периода времени и фиксировать, сколько создать и выполнить тест-кей- 
сов вы можете в час, день, неделю, месяц и т.д. Чем больший промежуток времени 
будет рассмотрен, тем меньше на результаты измерений будут влиять кратковре- 
менные отвлекающие факторы, появление которых сложно предсказывать. 

Допустим, что для некоторого выдуманного тестировщика эти значения ока- 
зались следующими — за месяц (28 рабочих дней) ему удаётся: 

e Создать 300 тест-кейсов (примерно 11 тест-кейсов в день, или 1.4 в час). 
• Выполнить 1000 тест-кейсов (примерно 36 тест-кейсов в день, или 4.5 в час). 


Подставим полученные значения в таблицу 2.6.а и получим таблицу 2.6.5. 


Таблица 2.6.6 — Оценка трудозатрат 


























Создание Выполнение 
Количество 12 22 
Повторения (проходы) 1 1.2 
Общее количество 12 26.4 
Время на один тест-кейс, ч 0.7 0.2 
Итоговое время, ч 8.4 5.2 
ИТОГО 13.6 часа 














Если бы оценка производительности нашего выдуманного тестировщика 
производилась на коротких отрезках времени, полученное значение нельзя было 
бы использовать напрямую, т.к. в нём не было бы учтено время на написание отчё- 
тов о дефектах, участие в различных собраниях, переписку и прочие виды деятель- 
ности. Но мы потому и ориентировались на итоги измерений за месяц, что за 28 
типичных рабочих дней все эти факторы многократно проявляли себя, и их влияние 
уже учтено в оценке производительности. 

Если бы мы всё же опирались на краткосрочные исследования, можно было 
бы ввести дополнительный коэффициент или использовать допущение о том, что 
работе с тест-кейсами за один день удаётся посвятить не 8 часов, а меньше (напри- 
мер, 6). 

Итого у нас получилось 13.6 часа, или 1.7 рабочих дня. Помня идею о за- 
кладке небольшого «буфера», можем считать, что за два полных рабочих дня наш 
выдуманный тестировщик точно справится с поставленной задачей. 

В заключение этой главы ещё раз отметим, что для уточнения собственной 
производительности и улучшения своих навыков оценки трудозатрат стоит форми- 
ровать оценку, после чего выполнять работу и сравнивать фактический результат 
с оценкой. И повторять эту последовательность шагов раз за разом. 





‚ Задание 2.6.с: разработайте на основе итогового чек-листа!', представ- 
 ленного в разделе 2.4, тест-кейсы и оцените свою производительность B 
роцессе выполнения этой задачи. 
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2.7. Примеры использования различных техник тестирования 


2.7.1. Позитивные и негативные тест-кейсы 


Ранее мы уже рассматривали" алгоритм продумывания идей тест-кейсов, 
в котором предлагается ответить себе на следующие вопросы относительно тести- 
руемого объекта: 
e Что перед вами? 
e Кому и зачем оно нужно (и насколько это важно)? 
e Как оно обычно используется? 
e Как оно может сломаться, т.е. начать работать неверно? 


Сейчас мы применим этот алгоритм, сконцентрировавшись на двух послед- 
них вопросах, т.к. именно ответы на них позволяют нам придумать много позитив- 
ных?” и негативных“ тест-кейсов. Продолжим тестировать наш «Конвертер фай- 
лове», выбрав для исследования первый параметр командной строки — 
ЗОЧАСЕ_ РІВ — имя каталога, в котором приложение ищет файлы, подлежащие 
конвертации. 


Что перед нами? Путь к каталогу. Казалось бы, просто, но стоит вспомнить, 
что наше приложение должно работать как минимум под управлением Windows 
и Ипих, что приводит к необходимости освежить в памяти принципы работы фай- 
ловых систем в этих ОС. А ещё может понадобиться работа с сетью. 


Кому и зачем оно нужно (и насколько это важно)? Конечные пользователи 
не занимаются конфигурированием приложения, т.е. этот параметр нужен админи- 
стратору (предположительно, это человек квалифицированный и не делает явных 
глупостей, но из его же квалификации вытекает возможность придумать такие ва- 
рианты использования, до которых не додумается рядовой пользователь). Важ- 
ность параметра критическая, т.к. при каких-то проблемах с ним есть риск полной 
потери работоспособности приложения. 


Как оно обычно используется? Здесь нам понадобится понимание прин- 
ципов работы файловых систем. 
e Корректное имя существующего каталога: 


о Windows: 
= Хлаіг 
= “Хл\аіг with spaces” 
= \dir 
" _\аіг 


" \\host\dir 
= Всё вышеперечисленное с “\” в конце пути. 


" ХЛ 
о Linux: 
= /аіг 
= “/dir with spaces” 
=  host:/dir 
= smb://host/dir 
" /dir 
= _/dir 
" Всё вышеперечисленное с “/” в конце пути. 
н / 
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И всё, т.е. в данном конкретном случае существует единственный вариант 
верного использования первого параметра — указать корректное имя существую- 
щего каталога (пусть вариантов таких корректных имён и много). Фактически мы 
получили чек-лист для позитивного тестирования. Все ли варианты допустимых 
имён мы учли? Может быть, и не все. Но эту проблему мы рассмотрим в следующей 
главе, посвящённой классам эквивалентности и граничным условиям?4. 

В настоящий момент важно ещё раз подчеркнуть мысль о том, что сначала 
мы проверяем работу приложения на позитивных тест-кейсах, т.е. в корректных 
условиях. Если эти проверки не пройдут, в некоторых совершенно допустимых и 
типичных ситуациях приложение будет неработоспособным, т.е. ущерб качеству 
будет весьма ощутимым. 


Как оно может сломаться, т.е. начать работать неверно? Негативных 
тест-кейсов (за редчайшим исключением) оказывается намного больше, чем пози- 
тивных. Итак, какие проблемы с именем каталога-источника (и самим каталогом- 
источником) могут помешать нашему приложению? 

e Указанный путь не является корректным именем каталога: 
о Пустое значение (“”). 
о Слишком длинное имя: 
= Для Windows: более 256 байт. (Важно! Путь к каталогу длиной B 
256 байт допустим, но надо учесть ограничение на полное имя 
файла, т.к. его превышение может быть достигнуто естествен- 
ным образом, что приведёт к возникновению сбоя.) 
= Для Linux: более 4096 байт. 
о Недопустимые символы, например: ? < > \ * | "\0. 
о Недопустимые комбинации допустимых символов, например: “....\dir”. 
e Каталог не существует: 
о На локальном диске. 
о Всети. 
e Каталог существует, но к нему нет прав доступа. 
e Доступ к каталогу утерян после запуска приложения: 
о Каталог удалён или переименован. 
о Изменены права доступа. 
о Потеря соединения с удалённым компьютером. 
e Использование зарезервированного имени: 
о Для Windows: сот1-сот9, 1рї1 -1рі9, con, nul, prn. 
о Для Linux: “..”. 
e Проблемы с кодировками, например: имя указано верно, но не в той коди- 
ровке. 


Если погружаться в детали поведения отдельных операционных систем и 
файловых систем, данный список можно значительно расширить. И тем не менее 
открытыми будут оставаться два вопроса: 

e Все ли эти варианты надо проверить? 
e Не упустили ли мы что-то важное? 


На первый вопрос ответ можно найти, опираясь на рассуждения, описанные 
в главе «Логика создания эффективных проверок». Ответ на второй вопрос NO- 
могут найти рассуждения, описанные в двух следующих главах, т.к. классы эквива- 
лентности, граничные условия и доменное тестирование значительно упрощают 
решение подобных задач. 
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‚ Задание 2.7.а: как вы думаете, почему в вышеприведённых чек-листах мы 
не учли требование о том, что SOURCE_DIR не может содержать внутри · 
бя ОЕЅТІМАТІОМ ВІВ? | 
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2.7.2. Классы эквивалентности и граничные условия 


В данной главе мы рассмотрим примеры упомянутых ранее техник тестиро- 
вания на основе классов эквивалентности?! и граничных условий. Если уточнить 
Ня получается: 


Класс эквивалентности (equivalence с!аз$3*7) — набор данных, обраба- 


‚ Граничное условие (border condition, boundary condition) — значение, 
находящееся на границе классов эквивалентности. 











Иногда под классом эквивалентности понимают набор тест-кейсов, NON- 
‚ ное выполнение которого является избыточным. Это определение не npo- 
 тиворечит предыдущему, т.к. показывает ту же ситуацию, но с другой · 





В качестве пояснения идеи рассмотрим тривиальный пример. Допустим, нам 
нужно протестировать функцию, которая определяет, корректное или некорректное 
имя ввёл пользователь при регистрации. 

Требования к имени пользователя таковы: 

e От трёх до двадцати символов включительно. 
• Допускаются цифры, знак подчёркивания, буквы английского алфавита в 
верхнем и нижнем регистрах. 


Если попытаться решить задачу «в лоб», нам для позитивного тестирования 
придётся перебрать все комбинации допустимых символов длиной [3, 20] (это 18- 
разрядное 63-ричное число, т.е. 2.4441614509104Е+32). А негативных тест-кейсов 
здесь и вовсе будет бесконечное количество, ведь мы можем проверить строку дли- 
ной в 21 символ, 100, 10000, миллион, миллиард ит.д. 


Представим графически классы эквивалентности относительно требований 
к длине (см. рисунок 2.7.а). 


Недопустимо Допустимо | Недопустимо | 








Недостижимо 


Рисунок 2.7.а — Классы эквивалентности для значений длины имени пользова- 
теля 


Поскольку для длины строки невозможны дробные и отрицательные значе- 
ния, мы видим три недостижимых области, которые можно исключить, и получаем 
окончательный вариант (см. рисунок 2.7.5). 

Мы получили три класса эквивалентности: 

e [0, 2] — недопустимая длина; 
e [3,20] — допустимая длина; 
e [21, =] — недопустимая длина. 





347 Ап equivalence class consists of а зе! ої data that is treated the same Бу а module ог that should produce the same result. [Lee 
Copeland, «A practitioner's guide to software test design»] 
348 The boundaries — the «edges» of each equivalence class. [Lee Copeland, «A practitioner's guide to software test design»] 
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Недопустимо | | Допустимо 





02 21 


Рисунок 2.7.6 — Итоговое разбиение на классы эквивалентности значений длины 
имени пользователя 


Обратите внимание, что области значений [0, 2] и [21, =] относятся к разным 
классам эквивалентности, т.к. принадлежность длины строки к этим диапазонам 
проверяется отдельными условиями на уровне кода программы. 

Граничные условия уже отмечены на рисунке 2.7.6 — это 2, 3, 20 и 21. 3Ha- 
чение 0 тоже стоит включить в этот набор на всякий случай, т.к. в программирова- 
нии ноль, NULL, нулевой байт и т.п. исторически являются «опасными значениями». 

В итоге мы получаем следующий набор входных данных для тест-кейсов 
(сами символы для составления строк можно выбирать из набора допустимых сим- 
волов случайным образом, но желательно учесть все типы символов, т.е. буквы в 
обоих регистрах, цифры, знак подчёркивания). 


Таблица 2.7.а — Значения входных данных для тест-кейсов (реакция на длину 
имени пользователя) 











Позитивные тест-кейсы Негативные тест-кейсы 
Значе- | ААА 123_zzzzzzzzzzzzzzzz | АА Пустая 1234 2222222272727722. 
ние строка 
Строка ми- | Строка максимальной Строка не- | Строка не- | Строка недопустимой 
нимальной | допустимой длины допустимой | допустимой | длины по верхней гра- 
Поясне- | допустимой длины по длины, нице 
ние длины нижней учтена для 
границе надёжно- 
сти 























Осталось решить вопрос с недопустимыми символами. К сожалению, столь 
же наглядно, как с длиной, здесь не получится. Даже если подойти строго научно, 
т.е. выбрать кодировку и по её кодовой таблице определить диапазоны кодов сим- 
волов (на рисунке 2.7.с приведён пример такого разделения для АЗС!-таблицы), у 
нас нет никакой гарантии, что символы с кодами из каждого диапазона трактуются 
ИЯ 





‚ Здесь мы видим ярчайший пример случая, в котором тестирование по Me- 
тоду белого ящика сильно облегчило бы нам жизнь. Если бы мы видели, | 
‚ Kak B коде приложения реализована проверка на допустимые и недопусти- ' 
мые символы, мы могли бы подобрать очень показательные значения · 





одных данных. 


[Цифры | == А-2 [| Буквы а-2 





48 57 95 97 
ГЕ пер 
к. 47 58 64 91 94 96 123 255 


Рисунок 2.7.с — Неудачный способ поиска классов эквивалентности для наборов 
допустимых и недопустимых символов (коды символов приведены по ASCII- 
таблице) 
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Раз оказалось, что по кодам символов подбирать классы эквивалентности в 
нашем случае нерационально, посмотрим на ситуацию по-другому (и намного 
проще). Поделим символы на недопустимые и допустимые, а последние, в свою 
очередь, — на группы (см. рисунок 2.7.4). 


Допустимо 


| Недопустимо 






















Буквы A-Z 






Все 
остальные 
символы 

















Рисунок 2.7.4 — Классы эквивалентных допустимых и недопустимых символов 


Интересующие нас комбинации допустимых символов (с представителями 
всех групп) мы уже учли при проверке реакции приложения на имена пользователя 
допустимых и недопустимых длин, потому остаётся учесть только вариант с допу- 
стимой длиной строки, но недопустимыми символами (которые можно выбирать 
случайным образом из соответствующего набора). В таблицу 2.7.а добавим одну 
колонку и получим таблицу 2.7.5. 


Таблица 2.7.6 — Значения всех входных данных для тест-кейсов 











Позитивные тест-кейсы Негативные тест-кейсы 
Зна- | ААА 123_zzzzzzzzzzzzzzzz | АА Пустая | 1234_zzzzzzzzzzzzzzzz | #$% 
чение строка 
Строка Строка максимальной Строка Строка Строка недопустимой Строка 
мини- допустимой длины недопу- | недопу- | длины по верхнейгра- допусти- 
мальной стимой стимой нице мой 
Пояс- | допусти- длины длины, длины, 
нение | мой по ниж- | учтена недопу- 
длины ней гра- | для стимые 
нице надёж- символы 
ности 
































онечно, в случае критически важных приложений (например, системы ` 
управления ядерным реактором) мы бы проверили с помощью средств aB- | 
' томатизации реакцию приложения на каждый недопустимый символ. Но | 
‚ предположив, что перед нами некое тривиальное приложение, мы можем | 





Теперь мы возвращаемся к «Конвертеру файлов»? и ищем ответ на BO- 
прос?32 о том, не упустили ли мы какие-то важные проверки в главе «Позитивные и 
негативные тест-кейсы» 22". 


Начнём с того, что выделим группы свойств SOURCE_DIR, от которых зави- 
сит работа приложения (такие группы называются «измерениями»): 
Существование каталога (изначальное и во время работы приложения). 
Длина имени. 

Наборы символов в имени. 

Комбинации символов в имени. 

Расположение каталога (локальный или сетевой). 

Права доступа к каталогу (изначальные и во время работы приложения). 
Зарезервированные имена. 
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e Поведение, зависящее от операционной системы. 
• Поведение, зависящее от работы сети. 


адание 2.7.0: какие ещё группы свойств вы бы добавили в этот список и · 





ак бы вы выделили подгруппы у уже имеющихся в списке свойств? 


Очевидно, что отмеченные группы свойств оказывают взаимное влияние. 
Графически его можно отобразить в виде концепт-картыз (рисунок 2.7.е). 


Права есть Существует 








Прав нет Не существует 


Изначально Во время работы 














Особенности работы 
сети 









Права доступа 


ПГ 


Локальный Сетевой 
Зарезервированное 


Недопустимые Допустимые Допустимая Недопустимая 


Недопустимые Комбинации символов Допустимые 











Особенности работы 
OC 






Существование 







SOURCE_DIR 
































Рисунок 2.7.е — Концепт-карта взаимовлияния групп свойств каталога 





349 «Concept тар», Wikipedia [http://en.wikipedia.org/wiki/Concept_map] 
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Чтобы иметь возможность применить стандартную технику классов эквива- 
лентности и граничных условий, нам нужно по рисунку 2.7.е дойти от центрального 
элемента («ЗОЧВАСЕ_ ОІВ») до любого конечного, однозначно относящегося к пози- 
тивному или негативному тестированию. 

Один из таких путей на рисунке 2.7.е отмечен кружками. Словесно его можно 
выразить так: SOURCE_DIR > Windows > Локальный каталог > Имя > Свободное 
> Длина > В кодировке ОТЕ16 > Допустимая или недопустимая. 

Максимальная длина пути для Windows в общем случае равна 256 байтам: 
[диск[\Г[путы] [пы = 1 + 2 + 256 + 1 = 260. Минимальная длина равна 1 байту (точка 
обозначает «текущий каталог»). Казалось бы, всё очевидно и может быть представ- 
лено рисунком 2.7.1. 





| Недопустимо | | Допустимо | 








0 257 


Рисунок 2.7.1 — Классы эквивалентности и граничные условия для длины пути 


Но если почитать внимательно спецификацию, выясняется, что «физиче- 
ски» путь может быть длиной до 32'767 символов, а ограничение в 260 символов 
распространяется лишь на т.н. «полное имя». Потому возможна, например, ситуа- 
ция, когда в каталог с полным именем длиной 200 символов помещается файл с 
именем длиной 200 символов, и длина полного имени файла получается равной 
400 символам (что очевидно больше 260). 

Так мы подошли к ситуации, в которой для проведения тестирования нужно 
либо знать внутреннюю реализацию поведения приложения, либо вносить правки 
в требования, вводя искусственные ограничения (например, длина имени 
SOURCE_DIR не может быть более 100 символов, а длина имени любого файла в 
SOURCE_DIR не может быть более 160 символов, что в сумме может дать макси- 
мальную длину в 260 символов). 

Ввод искусственных ограничений — плохая идея, потому с точки зрения ка- 
чества мы вполне вправе считать представленное на рисунке 2.7.1 разбиение кор- 
ректным, а сбои в работе приложения (если таковые будут), вызванные описанной 
выше ситуацией вида «200 символов + 200 символов», — дефектом. 


Таблица 2.7.с — Значения всех входных данных для тест-кейсов по проверке вы- 
бранного на рисунке 2.7.е пути 


























Позитивные тест-кейсы Негативные тест-кейсы 
Зна- |. (точка) С\әзвбайт Пустая строка С:\л57байт 
чение 
Пояс- Имя с Я Имя с максимальной Имя с недопустимой Имя с недопустимой длиной 
Henne мальной допу- допустимой длиной длиной, учтено для 
стимой длиной надёжности 








Итак, с одним путём на рисунке 2.7.е мы разобрались. Но их там значительно 
больше, и потому в следующей главе мы рассмотрим, как быть в ситуации, когда 
приходится учитывать влияние на работу приложения большого количества пара- 
метров. 





350 «Naming Files, Paths, апа Namespaces», MSDN [https://msdn.microsoft.com/en-us/library/aa365247.aspx#maxpath] 
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2.7.3. Доменное тестирование и комбинации параметров 


Уточним данное ранее? определение: 





| (т) ‚ Доменное тестирование (domain testing, domain апа!уз!35') — техника co- 
здания эффективных и результативных тест-кейсов в случае, когда He- 
сколько переменных могут или должны быть протестированы одновре- 





В качестве инструментов доменного тестирования активно используются 
техники определения классов эквивалентности и граничных условий, которые были 
рассмотрены в соответствующей?“ главе. Потому мы сразу перейдём к практиче- 
скому примеру. 

На рисунке 2.7.е кружками отмечен путь, один из вариантов которого мы рас- 
смотрели в предыдущей главе, но вариантов может быть много: 

e Семейство ОС 
о Windows 
о Linux 
• Расположение каталога 
о Локальный 
о Сетевой 
• Доступность имени 
о Зарезервированное 
о Свободное 
• Длина 
о Допустимая 
о Недопустимая 


Чтобы не усложнять пример, остановимся на этом наборе. Графически ком- 
бинации вариантов можно представить в виде иерархии (см. рисунок 2.7.9). Исклю- 
чив совсем нетипичную для нашего приложения экзотику (всё же мы не разрабаты- 
ваем сетевую утилиту), вычеркнем из списка случаи зарезервированных сетевых 
имён (отмечены на рисунке 2.7.9 серым). 

Легко заметить, что при всей своей наглядности графическое представление 
не всегда удобно в обработке (к тому же мы пока ограничились только общими иде- 
ями, не отметив конкретные классы эквивалентности и интересующие нас значения 
граничных условий). 

Альтернативным подходом является представление комбинаций в виде таб- 
лицы, которое можно получать последовательно за несколько шагов. 

Сначала учтём комбинации значений первых двух параметров — семейства 
ОС и расположения каталога. Получается таблица 2.7.4. 


Таблица 2.7.а — Комбинации значений первых двух параметров 

















Windows Linux 
Локальный путь + + 
Сетевой путь + + 








На пересечении строк и столбцов можно отмечать необходимость выполне- 
ния проверки (в нашем случае таковая есть, потому там стоит «+») или её отсут- 
ствие, приоритет проверки, отдельные значения параметров, ссылки и т.д. 





351 Domain analysis is а technique that сап бе used to identify efficient апа effective test cases when multiple variables сап ог 
should be tested together. [Lee Copeland, «A practitioner's guide to software test design»] 
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Допустимая 


тимая 


Допустимая 


5 Зарезерви- Недопус- 
Локальный РСВ ЭЕШ 
рованное тимая 


Допустимая 


тимая 


Допустимая 


| 5 Зарезерви- Недопус- 
Windows Сетевой РЕ Шеп 
рованное тимая 
; 5 Зарезерви- Недопус- 
Linux Сетевой 
рованное тимая 


SOURCE DIR 


Допустимая 
тимая 


Допустимая 


Н Зарезерви- Недопус- 
Локальный резер АРХ 
рованное тимая 


Допустимая 


тимая 


Допустимая 


Рисунок 2.7.9 — Графическое представление комбинаций параметров 
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Добавим третий параметр (признак зарезервированного имени) и получим 


таблицу 2.7.е. 


Таблица 2.7.е — Комбинации значений трёх параметров 


























Windows Linux 
Зарезервирован- Локальный путь + + 
ное имя Сетевой путь Е Š 
Локальный путь + + 
Свободное имя с 
Сетевой путь + + 











Добавим четвёртый параметр (признак допустимости длины) и получим таб- 
лицу 2.7.1. 

Чтобы таблица равномерно увеличивалась по высоте и ширине, удобно до- 
бавлять каждый последующий параметр попеременно — то как строку, то как стол- 
бец (при формировании таблиц 2.7.е и 2.7.1 третий параметр мы добавили как 
строку, четвёртый — как столбец). 


Таблица 2.7.1 — Комбинации значений четырёх параметров 




















Недопустимая длина Допустимая длина 
Windows Linux Windows Linux 
Локальный А А 2 К 
Зарезервиро- путь 
ванное имя Сетевой _ 1 _ А 
путь 
Локальный 
+ + + + 
Свободное путь 
имя Сетевой 
+ + + + 
путь 


























Такое представление по сравнению с графическим оказывается более ком- 
пактным и позволяет очень легко увидеть комбинации значений параметров, кото- 
рые необходимо подвергнуть тестированию. Вместо знаков «+» в ячейки можно по- 
ставить ссылки на другие таблицы (хотя иногда все данные совмещают в одной 
таблице), в которых будут представлены классы эквивалентности и граничные 
условия для каждого выбранного случая. 

Как несложно догадаться, при наличии большого количества параметров, 
каждый из которых может принимать много значений, таблица наподобие 2.7.1 бу- 
дет состоять из сотен строк и столбцов. Даже её построение займёт много времени, 
а выполнение всех соответствующих проверок и вовсе может оказаться невозмож- 
ным в силу нехватки времени. В следующей главе мы рассмотрим ещё одну технику 
тестирования, призванную решить проблему чрезмерно большого количества ком- 
бинаций. 
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2.7.4. Попарное тестирование и поиск комбинаций 


Уточним данное ранее? определение: 





(т) _Попарное тестирование (pairwise testing?) — техника тестирования, в | 
‚ которой вместо проверки всех возможных комбинаций значений всех na- 
‚ раметров проверяются только комбинации значений каждой пары napa- 





Выбрать и проверить пары значений — звучит вроде бы просто. Но как вы- 
бирать такие пары? Существует несколько тесно взаимосвязанных математических 
методов создания комбинаций всех пар: 
на основе ортогональных массивовз53, 357; 
на основе латинских квадратов“; 

ІРО (іп parameter order) методз; 
на основе генетических алгоритмовз%; 
на основе рекурсивных алгоритмов. 





Глубоко в основе этих методов лежит серьёзная математическая Teo- 
рия”. В упрощённом виде на примерах суть и преимущества этого под- 
‚ хода показаны в книге Ли Коуплендаз и статье Майкла Болтоназѕ, а спра- 

дливая критика — в статье Джеймса Баха?°°. | 





Итак, суть проблемы: если мы попытаемся проверить все сочетания всех 
значений всех параметров для более-менее сложного случая тестирования, мы по- 
лучим количество тест-кейсов, превышающее все разумные пределы. 

Если представить изображённую на рисунке 2.7.е схему в виде набора пара- 
метров и количества их значений, получается ситуация, представленная таблицей 
2.7.0. Минимальное количество значений получено по принципу «расположение: 
локально или в сети», «существование: да или нет», «семейство ОС: Windows или 
Linux» и т.д. Вероятное количество значений оценено исходя из необходимости 
учитывать несколько классов эквивалентности. Количество значений с учётом пол- 
ного перебора получено исходя из технических спецификаций операционных си- 
стем, файловых систем и т.д. Значение нижней строки получено перемножением 
значений в соответствующей колонке. 





352 The answer is пої to attempt їо test all the combinations for all the values for а! the variables but to test all pairs ої variables. [Lee 
Copeland, «A practitioner's guide to software test design»] 

353 «Pairwise Testing», Michael Bolton [http:/www.developsense.com/pairwiseTesting.html] 

354 «An Improved Test Generation Algorithm for Pair-Wise Testing», Soumen Maity and oth. [https://citeseerx.ist.-psu.edu/view- 
doc/download?doi=10.1.1.147.2164&rep=rep1&type=pdf] 

355 «А Test Generation Strategy for Pairwise Testing», Kuo-Chung Tai, Yu Lei [https://citeseerx.ist.psu.edu/viewdoc/down- 
load?doi=10.1.1.106.8350&rep=rep1&type=pdf] 

356 «Evolutionary Algorithm for Prioritized Pairwise Test Data Generation», Javier Ferrer and oth. 
[https://neo.lcc.uma.es/staff/javi/files/gecco12.pdf] 

357 «On the Construction of Orthogonal Arrays and Covering Arrays Using Permutation Groups», George Sherwood 
[http://testcover.com/pub/background/cover.htm] 

358 «A Practitioner's Guide to Software Test Design», Lee Copeland. 

359 «Pairwise Testing: A Best Practice That Isn't», James Bach [http://citeseerx.ist.psu.edu/viewdoc/down- 
load?doi=10.1.1.105.3811&rep=rep1&type=pdf]. 
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Таблица 2.7.0 — Список параметров, влияющих на работу приложения 
































Параметр Минимальное | Вероятное | Количество значе- 
количество количество | ний с учётом пол- 
значений значений ного перебора 
Расположение 2 25 32 
Существование 2 2 2 
Наличие прав доступа 2 З 155 
Семейство ОС 2 4 28 
Зарезервированное или свободное имя 2 7 23 
Кодировки 2 3 16 
Длина 2 4 4096 
Комбинации символов 2 4 82 
ИТОГО тест-кейсов 256 201’600 34'331'384'872'960 




















Конечно, мы не будем перебирать все возможные значения (для того нам и 
нужны классы эквивалентности), но даже 256 тест-кейсов для проверки всего лишь 
одного параметра командной строки — это много. И куда вероятнее, что придётся 
выполнять около 200 тысяч тест-кейсов. Если делать это вручную и выполнять по 
одному тесту в пять секунд круглосуточно, понадобится около 11 суток. 

Но мы можем применить технику попарного тестирования для генерации оп- 
тимального набора тест-кейсов, учитывающего сочетание пар каждого значения 
каждого параметра. Опишем сами значения. Обратите внимание, что уже на этой 
стадии мы провели оптимизацию, собрав в один набор информацию о расположе- 
нии, длине, значении, комбинации символов и признаке зарезервированного имени. 
Это сделано потому, что сочетания вида «длина 0, зарезервированное имя соті» 
не имеют смысла. Также мы усилили часть проверок, добавив русскоязычные 
названия каталогов. 


Таблица 2.7.һ — Список параметров и их значений 





Параметр Значения 
Расположение / длина / зна- XA 
чение / комбинация симво- Хлаіг 
лов / зарезервированное или “Х\пробелы и русский” 
свободное Лаіг 
.\dir 
\\host\dir 
[256 байт только для Windows] 
+ Пункты 2-6 с “V в конце пути. 





мо отр: го 


8. / 
9. /dir 
10. “/пробелы и русский” 
11. host:/dir 
12. smb://host/dir 
13. ./dir 
14. ../аіг 
15. [4096 байт только для Шпих] 
+ Пункты 9-14 с “/” в конце пути. 


Недопустимое имя. 
16. [0 символов] 
17. [4097 байт только для Шпих] 
18. [257 байт только для Windows] 
19." 
20. // 
21.\ 
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22... 

23. сот1-сот9 

24. рИ -1рї9 

25. соп 

26. nul 

27. prn 

Да 

Нет 

К каталогу и его содержимому 
Только к каталогу 

Ни к каталогу, ни к его содержимому 
Windows 32 bit 

Windows 64 bit 

Linux 32 bit 

Linux 64 bit 

UTF8 

UTF16 

OEM 





Существование 





Наличие прав доступа 





Семейство ОС 





Кодировки 











оо го |Р © № [0 № >N > 





Количество потенциальных тест-кейсов уменьшилось до 2736 (38*2*3*4*3), 
что уже много меньше 200 тысяч, но всё равно нерационально. 

Теперь воспользуемся любым из представленных в огромном количестве ин- 
струментальных средств? (например, РІСТ) и сгенерируем набор комбинаций на 
основе попарного сочетания всех значений всех параметров. Пример первых де- 
сяти строк результата представлен в таблице 2.7.1. Всего получилось 152 комбина- 
ции, т.е. в 1326 раз меньше (201'600 / 152) исходной оценки или в 18 раз меньше 
(2736 / 152) оптимизированного варианта. 


Таблица 2.7.1 — Наборы значений, полученные методом попарных комбинаций 


















































№ | Расположение / длина/ | Существо- | Наличие прав до- Семейство | Кодировки 
значение / комбинация вание ступа ОС 
символов / зарезерви- 
рованное или свобод- 
ное 
1 ХА Да К каталогу и его со- Windows 64 | UTF8 
держимому bit 
2 | smb://host/dir/ Нет Ни к каталогу, ни к Windows 64 | UTF16 
его содержимому bit 
3 |/ Нет Только к каталогу Windows 32 | ОЕМ 
bit 
4 | [0 символов] Да Только к каталогу Linux 32 bit | UTF8 
5 | smb://host/dir Нет К каталогу и его со- Linux 32 bit | UTF16 
держимому 
6 ../а Да Ни к каталогу, ни к Linux 64 bit | ОЕМ 
его содержимому 
7 | [257 байт только для Да Только к каталогу Windows 64 | ОЕМ 
Windows] bit 
8 | [4096 байт только для Нет Ни к каталогу, ни к Windows 32 | UTF8 
Linux] его содержимому bit 
9 | [256 байт только для Нет Ни к каталогу, ни к Linux 32 bit | ОЕМ 
Windows] его содержимому 
10 | /dir/ Да Только к каталогу Windows 32 | UTF16 
bit 











Если исследовать набор полученных комбинаций, можно исключить из них 


те, которые не имеют смысла (например, существование каталога с именем нуле- 
вой длины или проверку под Windows характерных только для Linux случаев — см. 





360 «Pairwise Testing, Available Tools» [https://jaccz.github.io/pairwise/tools.html] 
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строки 4 и 8). Завершив такую операцию, мы получаем 124 комбинации. По сооб- 
ражениям экономии места эта таблица не будет приведена, но в приложении «При- 
мер данных для попарного тестирования» ?°% представлен конечный итог оптимиза- 
ции (из таблицы убраны ещё некоторые комбинации, например, проверка под Linux 
имён, являющихся зарезервированными для Windows). Получилось 85 тест-кейсов, 
что даже немного меньше минимальной оценки в 256 тест-кейсов, и при этом мы 
учли куда больше опасных для приложения сочетаний значений параметров. 





| (5 адание 2.7.с: в представленной в приложении «Пример данных для NO- 
‚ парного тестирования»? в колонке «Наличие прав доступа» иногда oT- 
‚ сутствуют значения. Как вы думаете, почему? Также в этой таблице всё 
ещё есть «лишние» тесты, выполнение которых не имеет смысла или | 
‚представляет собой крайне маловероятный вариант стечения событий. | 
‚ Найдите их. | 


Итак, на протяжении последних четырёх глав мы рассмотрели несколько тех- 
ник тестирования, позволяющих определить наборы данных и идей для написания 
эффективных тест-кейсов. Следующая глава будет посвящена ситуации, когда вре- 
мени на столь вдумчивое тестирование нет. 
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2.7.5. Исследовательское тестирование 


Исследовательское2 и свободное? тестирование уже было упомянуто pa- 
нее на уровне определения. Для начала ещё раз подчеркнём, что это разные виды 
тестирования, пусть в каждом из них степень формализации процесса значительно 
меньше, чем в тестировании на основе тест-кейсов®*. Сейчас мы будем рассмат- 
ривать применение именно исследовательского тестирования. 

Сэм Канер определяет! исследовательское тестирование как стиль, OCHO- 
ванный на свободе и ответственности тестировщика в непрерывной оптимизации 
своей работы за счёт выполняемых параллельно на протяжении всего проекта и 
взаимодополняющих изучения, планирования, выполнения проверок и оценки их 
результатов. Если сказать короче, исследовательское тестирование — это одно- 
временное изучение, планирование и тестирование. 

Кроме очевидной проблемы с тестированием на основе тест-кейсов, состоя- 
щей в высоких затратах времени, существует ещё одна — существующие техники 
оптимизации направлены на то, чтобы максимально исследовать приложение во 
всех учтённых ситуациях, которые мы можем контролировать — но невозможно 
учесть и проконтролировать всё. Эта идея визуально представлена на рисунке 
2.7.1. 


Неучтённые состояния ОС и Неучтённые состояния ОС и 
среды выполнения среды выполнения 
Неучтённые состояния Неучтённые состояния 
компонентов приложения компонентов приложения 


Контролируемое 
поведение 


Подготовленные 
данные и команды 


Неучтённые состояния Неучтённые воздействия на 
конфигураций и ресурсов разнообразные ресурсы 


Неучтённые воздействия Неучтённые воздействия на 


других приложений другие приложения 


Приложение 


Рисунок 2.7.1 — Факторы, которые могут быть пропущены тестированием на OC- 
нове тест-кейсовзе! 


Исследовательское же тестирование часто позволяет обнаружить дефекты, 
вызванные этими неучтёнными факторами. К тому же оно прекрасно показывает 
себя в следующих ситуациях: 

e Отсутствие или низкое качество необходимой документации. 

• Необходимость быстрой оценки качества при нехватке времени. 

• Подозрение на неэффективность имеющихся тест-кейсов. 

• Необходимость проверить компоненты, разработанные «третьими сторо- 
нами». 

• Верификация устранения дефекта (для проверки, что он не проявляется при 
незначительном отступлении от шагов воспроизведения). 





361 «А Tutorial іп Exploratory Testing», Сет Kaner [http://www.kaner.com/pdfs/QAIExploring.paf] 
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В своей работезе! Сэм Канер подробно показывает способы проведения nc- 
следовательского тестирования с использованием базовых методов, моделей, при- 
меров, частичных изменений сценариев, вмешательства в работу приложения, про- 
верки обработки ошибок, командного тестирования, сравнения продукта с требова- 
ниями, дополнительного исследования проблемных областей и т.д. 

Вернёмся к нашему «Конвертеру файлов» °?. Представим следующую ситу- 
ацию: разработчики очень уж быстро выпустили первый билд, тест-кейсов (и всех 
тех наработок, что были рассмотрены ранее в этой книге) у нас пока нет, а прове- 
рить билд нужно. Допустим, в уведомлении о выходе билда сказано: «Реализованы 
и готовы к тестированию требования: СХ-1, СХ-2, СХ-3, ПТ-1.1, ПТ-1.2, ПТ-2.1, ПТ- 
3.1, ПТ-3.2, БП-1.1, БП-1.2, ДС-1.1, ДС-2.1, ДС-2.2, ДС-2.3, ДС-2.4, ДС-3.1, ДС-3.2 
(текст сообщений приведён к информативному виду), ДС-4.1, ДС-4.2, ДС-4.3». 


Ранее мы отметили, что исследовательское тестирование — это тесно взаи- 
мосвязанные изучение, планирование и тестирование. Применим эту идею. 


Изучение 


Представим полученную от разработчиков информацию в виде таблицы 2.7.) 
и проанализируем соответствующие требования, чтобы понять, что нам нужно бу- 
дет сделать. 


Таблица 2.7.) — Подготовка к исследовательскому тестированию 













































































Требование Что и как будем делать 
СХ-1 Не требует отдельной проверки, т.к. вся работа с приложением будет выпол- 
няться в консоли. 
СХ-2 Не требует отдельной проверки, видно по коду. 
СХ-3 Провести тестирование под Windows и Linux. 
ПТ-1.1 Стандартная проверка реакции консольного приложения на различные вари- 
ДС-2.1 анты указания параметров. Учесть, что обязательными являются первые два 
ДС-2.2 параметра из трёх (третий принимает значение по умолчанию, если не задан). 
пС-2.8 См. «Идеи», пункт 1. 
ДС-2.4 
ПТ-1.2 См. «Идеи», пункт 2. 
ПТ-2.1 Не требует отдельной проверки, покрывается другими тестами. 
ПТ-3.1 На текущий момент можно только проверить факт ведения лога и формат за- 
ПТ-3.2 писей, т.к. основная функциональность ещё не реализована. См. «Идеи», 
ДС-4.1 пункт 4. 
ДС-4.2 
ДС-4.3 
БП-1.1 См. «Идеи», пункт З. 
БП-1.2 
ДС-1.1 Тестирование проводить на РНР 5.5. 
ДС-3.1 Проверять выводимые сообщения в процессе выполнения пунктов 1-2 (см. 
ДС-3.2 «Идеи». 
Планирование 


Частично планированием можно считать колонку «Что и как будем делать» 
таблицы 2.7.ј, но для большей ясности представим эту информацию в виде обоб- 
щённого списка, который для простоты назовём «идеи» (да, это — вполне класси- 
ческий чек-лист). 
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Идеи: 
1. Проверить сообщения в ситуациях запуска: 
а. Без параметров. 
р. С верно указанными одним, двумя, тремя параметрами. 
с. С неверно указанными первым, вторым, третьим, одним, двумя, тремя 
параметрами. 
2. Остановить приложение по Ctrl+C. 
3. Проверить сообщения в ситуациях запуска: 
а. Каталог-приёмник и каталог-источник в разных ветках ФС. 
р. Каталог-приёмник внутри каталога-источника. 
с. Каталог-приёмник, совпадающий с каталогом-источником. 
4. Проверить содержимое лога. 
5. Посмотреть в код классов, отвечающих за анализ параметров командной 
строки и ведение лога. 








‚ Задание 2.7.4: сравните представленный набор идей с ранее рассмотрен- 
ными подходами! 49). (231), (234), {233}, (242) — какой вариант вам кажется более npo- 





Итак, список идей есть. Фактически, это почти готовый сценарий, если пункт 
2 (про остановку приложения) повторять в конце проверок из пунктов 1 и З). 


Тестирование 


Можно приступать к тестированию, но стоит отметить, что для его проведе- 
ния нужно привлекать специалиста, имеющего богатый опыт работы с консольными 
приложениями, иначе тестирование будет проведено крайне формально и ока- 
жется неэффективным. 

Что делать с обнаруженными дефектами? Для начала — фиксировать в та- 
ком же формате, т.е. как список идей: переключение между прохождением некоего 
сценария и написанием отчёта о дефекте сильно отвлекает. Если вы опасаетесь 
что-то забыть, включите запись происходящего на экране (отличный трюк — запи- 
сывать весь экран так, чтобы были видны часы, а в списках идей отмечать время, 
когда вы обнаружили дефект, чтобы потом в записи его было проще найти). 

Список «идей дефектов» можно для удобства оформлять в виде таблицы 
(см. таблицу 2.7.К). 


Таблица 2.7.К — Список «идей дефектов» 











№ Что делали Что получили Что ожидали / Что не так 
о | а) Во всех случаях сообщения приложения вполне корректны с точки зрения происходящего 
и информативны, но противоречат требованиям (обсудить с заказчиком изменения в требо- 
ваниях). 

б) Лог ведётся, формат даты-времени верный, но нужно уточнить, что в требованиях име- 
ется в виду под «имя операции параметры_операции результат_операции», т.к. для разных 
операций единый формат не очень удобен — нужно ли приводить всё к одному формату 




















или нет? 

1 php converter.php Error: Too few command line parameters. Сообщение совершенно не 
USAGE: php сопуецег.рпр SOURCE_DIR | соответствует требованиям. 
РЕЅТІМАТІОМ РІВ [LOG_FILE_NAME] 
Please note that РЕЗТИМАТЮМ_О!А тау 
МОТ be inside SOURCE_DIR. 

2 php converter.php zzz:/ с:/ Error: SOURCE_DIR name [222:] is not a Странно, что от «222:/» оста- 
valid directory. ЛОСЬ ТОЛЬКО «222:». 
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3 php converter.php "c:/non/exist- Error: SOURCE_DIR пате [c:\non\exist- Слеши заменены Ha бэк- 
ing/directory/" с:/ іпо\аігесїогу] is пої а valid directory. слеши, конечный бэк-слеш 
удалён: таки надо? Глянуть в 
коде, пока не ясно, дефект 
это или так и задумано. 














4 php converter.php с:/ а:/ 2015.06.12 13:37:56 Started with parame- Буквы дисков приведены к 
ters: SOURCE_DIR=[C\], DESTINA- верхнему регистру, слеши 3a- 
TION_DIR=[D:\\], менены на бэк-слеши. Mo- 
LOG_FILE_NAME=[.\converter.log] чему имя лог-файла относи- 

тельное? 

5 | php converter.php с:/ с:/ Error: ОЕЗТИМАТЮМ ВІА [С:\] апа Опечатка в сообщении. Явно 
ЅОЦВСЕ РІА [СА] mat МОТ бе {не same | должно быть must или тау. 
dir. 

6 | php converter.php "с:/каталогс Error: SOURCE_DIR пате [с\ърЄрыюу ë | Дефект: проблема с кодиров- 

русским именем!" с:/ Ёєёёъшь шьхэхь] is пої а valid directory. ками. 

7 php сопуейег.рһр / c:/Win- Error: SOURCE_DIR пате [] is пої а valid Проверить под Шпих: мало- 

аомѕ/Тетр directory. вероятно, конечно, что кто-то 


прямо в / будет что-то рабо- 
чее хранить, но имя «/» уре- 
зано до пустой строки, что до- 
пустимо для Windows, но не 








для Linux. 
8 | Примечание: «е:» -- DVD- file _put_con- Дефект: сообщение от PHP 
привод. tents(e:f41c7142310c5910e2cfb57993b4d | не перехвачено. 
php сопуенпег.рйр с:/ е:/ 004620ааЗЬ8): failed to open stream: Per- 
mission denied іп \classes\CLPAna- 
lyser.class.php at line 70 Error: DESTINA- 
TION_DIR [e] is not writeable. 
9 | php converter.php /var/www Error: SOURCE_DIR name [var/www] is Дефект: B Linux обрезается 
маг/^м\\у/1 пої а valid directory. начальный «/» в имени ката- 


лога, т.е. можно смело счи- 
тать, что под Шпих приложе- 
ние неработоспособно 
(можно задавать только отно- 
сительные пути, начинающи- 
еся с «.» или «..»). 




















Выводы по итогам тестирования (которое, к слову, заняло около получаса): 

• Нужно подробно обсудить с заказчиком форматы и содержание сообщений 
об использовании приложения и об ошибках, а также формат записей лог- 
файла. Разработчики предложили идеи, выглядящие куда более адекватно, 
чем изначально описано в требованиях, но всё равно нужно согласование. 

• Под Windows серьёзных дефектов не обнаружено, приложение вполне рабо- 
тоспособно. 

e Под Linux есть критическая проблема с исчезновением «/» в начале пути, что 
не позволяет указывать абсолютные пути к каталогам. 

• Если обобщить вышенаписанное, то можно констатировать, что дымовой 
тест успешно пройден под Windows и провален под Linux. 


Цикл «изучение, планирование, тестирование» можно многократно повто- 
рить, дополняя и рассматривая список обнаруженных проблем (таблица 2.7.К) как 
новую информацию для изучения, ведь каждая такая проблема даёт пищу для раз- 
мышлений и придумывания дополнительных тест-кейсов. 





Задание 2.7.е: опишите дефекты, представленные в таблице 2.7.К в виде 
‚ полноценных отчётов о дефектах. 
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В данной главе в таблице 2.7.К некоторые пункты представляют собой оче- 
видные дефекты. Но что их вызывает? Почему они возникают, как могут прояв- 
ляться и на что влиять? Как описать их максимально подробно и правильно в отчё- 
тах о дефектах? Ответам на эти вопросы посвящена следующая глава, в которой 
мы поговорим о поиске и исследовании причин возникновения дефектов. 


2.7.6. Поиск причин возникновения дефектов 


Ранее мы отмечали, что используем слово «дефект» для обозначения 
проблемы потому, что описание конечного симптома несёт мало пользы, а выясне- 
ние исходной причины может быть достаточно сложным. И всё же наибольший эф- 
фект приносит как раз определение и устранение первопричины, что позволяет 
снизить риск появления новых дефектов, обусловленных той же самой (ненайден- 
ной и неустранённой) недоработкой. 





Hanns первопричин (root cause апа!уѕіѕзе2) — процесс исследования и 
классификации первопричин возникновения событий, негативно влияю- 
щих на безопасность, здоровье, окружающую среду, качество, надёжность · 

производственный процесс. 





Как видно из определения, анализ первопричин не ограничивается разработ- 
кой программ, но нас он будет интересовать всё же в ИТ-контексте. Часто ситуация, 
в которой тестировщик пишет отчёт о дефекте, может быть отражена рисунком 2.7.1. 


Наблюдаемое проявление 
Причина М№-1 





Условия, способствовавшие 
возникновению первопричины 





Рисунок 2.7.1 — Проявление и причины дефекта 


В самом худшем случае проблема вообще будет пропущена (не замечена), 
и отчёт о дефекте не будет написан. Чуть лучше выглядит ситуация, когда отчёт 
описывает исключительно внешние проявления проблемы. Приемлемым может 
считаться описание лежащих на поверхности причин. Но в идеале нужно стре- 
миться добраться до двух самых нижних уровней — первопричины и условий, спо- 





362 Root cause analysis (RCA) is а process designed for use іп investigating апа categorizing the root causes of events with 
safety, health, environmental, quality, reliability and production impacts. [James Rooney and Lee Vanden Heuvel, «Root Cause 
Analysis for Beginners», https://www.abs-group.com/content/documents/rca_for_begineers.pdf] 
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собствовавших её возникновению (хоть последнее часто и лежит в области управ- 
ления проектом, а не тестирования как такового). 


Вкратце вся эта идея выражается тремя простыми пунктами. Нам нужно по- 
нять: 
• Что произошло. 
• Почему это произошло (найти первопричину). 
• Как снизить вероятность повторения такой ситуации. 


Сразу же рассмотрим практический пример. В таблице 2.7.К в строке с номе- 
ром 9:49 есть упоминание крайне опасного поведения приложения под Linux — из 
путей, переданных приложению из командной строки, удаляется начальный символ 
«/», что для Linux приводит к некорректности любого абсолютного пути. 

Пройдём по цепочке, представленной рисунком 2.7.1, и отразим этот путь таб- 
лицей 2.7.1: 


Таблица 2.7.| — Пример поиска первопричины 








Уровень анализа Наблюдаемая ситуация Рассуждения и выводы 
Наблюдаемое Тестировщик выполнил команду «php Сразу же бросается в глаза, 
проявление про- сопуецег.рИр /var/www /var/www/1» и no- что в сообщении об ошибке 
блемы лучил такой ответ приложения: «Error: имя каталога отличается от 


SOURCE_DIR пате [var/www] is not а valid | заданного — отсутствует 
directory.» в ситуации, когда указанный Ka- | начальный «/». Несколько KOH- 
талог существует и доступен для чтения. трольных проверок подтвер- 
ждают догадку — во всех па- 
раметрах командной строки 
начальный «/» удаляется из 
полного пути. 




















а этом этапе очень часто начинающие тестировщики описывают дефект | 
| ‚ как «неверно распознаётся имя каталога», «приложение не обнаруживает | 
‚ доступные каталоги» и тому подобными словами. Это плохо как минимум _ 
по двум причинам: а) описание дефекта некорректно; б) программисту | 





Таблица 2.7 І [продолжение] 




















Уровень анализа Наблюдаемая ситуация Рассуждения и выводы 

Причина М Факт: во всех параметрах командной Дело явно в обработке вве- 
строки начальный «/» удаляется из пол- дённых имён: в некоторых 
ного пути. Проверка с относительными пу- | случаях имя обрабатывается 
тями («php converter.php . .») и проверка корректно, в некоторых — нет. 
под Windows («php converter.php сл d:\») Гипотеза: убираются началь- 
показывает, что в таких ситуациях прило- | ные и концевые «/» (может 
жение работает. быть, ещё и «\»). 

Причина N-1 Проверки «php converter. php \\\\\с:\\\\\ Гипотеза подтвердилась: из 
\\\\\dA\\\> и «php converter.php /////с:///// имён каталогов приложение 
ИИА!» показывают, что приложение под | убирает все «/» и «\», в любом 
Windows запускается, корректно распо- количестве присутствующие в 
знав правильные пути: «Started with начале или конце имени. 
parameters: SOURCE_DIR=[C\], 
DESTINATION_DIR=[D\]» 








В принципе, на этой стадии уже можно писать отчёт о дефекте с кратким опи- 
санием в стиле «Удаление краевых “/” и “P из параметров запуска повреждает аб- 
солютные пути в Ипих ФС». Но что нам мешает пойти ещё дальше? 


Таблица 2.7 І [продолжение] 
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Уровень анализа 


Наблюдаемая ситуация 


Рассуждения и выводы 





Причина №-2 


Гипотеза: где-то в коде есть первичный 
фильтр полученных значений путей, кото- 
рый обрабатывает их до начала проверки 
каталога на существование. Этот фильтр 
работает некорректно. Откроем код 
класса, отвечающего за анализ парамет- 
ров командной строки. Очень быстро мы 
обнаруживаем метод, который виновен в 


Мы нашли конкретное место в 
коде приложения, которое яв- 
ляется первопричиной обна- 
руженного дефекта. Информа- 
цию об имени файла, номере 
строки и выдержку самого 
кода с пояснениями, что в нём 
неверно, можно приложить в 


комментарии к отчёту о де- 
фекте. Теперь программисту 
намного проще устранить про- 


| блему. 
$name = зір гер1асе ('\\', '/', $name); 


происходящем: 


private function getCanonicalName ($name) 


Ѕагг = explode ('/', $name); 

$name = trim (implode (DIRECTORY _ SEPARATOR, 
$arr), DIRECTORY_SEPARATOR) ; 

return $name; 


} 





















Задание 2.7.f: представьте, что программист исправил проблему сменой | 
‚ удаления краевых «/» и «\» на концевые (т.е. теперь они удаляются только _ 
‚ в конце имени, но не в начале). Хорошее ли это решение? | 





Обобщённый алгоритм поиска первопричин можно сформулировать следую- 
щим образом (см. рисунок 2.7.)): 
e Определить проявление проблемы 
о Что именно происходит? 
о Почему это плохо? 
• Собрать необходимую информацию 
о Происходит ли то же самое в других ситуациях? 
о Всегда ли оно происходит одинаковым образом? 
о Отчего зависит возникновение или исчезновение проблемы? 
e Выдвинуть гипотезу о причине проблемы 
о Что может являться причиной? 
о Какие действия или условия могут приводить к проявлению про- 
блемы? 
о Какие другие проблемы могут быть причинами наблюдаемой про- 
блемы? 
e Проверить гипотезу 
о Провести дополнительное исследование. 
о Если гипотеза не подтвердилась, проработать другие гипотезы. 
• Убедиться, что обнаружена именно первопричина, а не очередная причина в 
длинной цепи событий 
о Если обнаружена первопричина — сформировать рекомендации по её 
устранению. 
о Если обнаружена промежуточная причина, повторить алгоритм для 
неё. 





Здесь мы рассмотрели очень узкое применение поиска первопричин. Но | 
‚ представленный алгоритм универсален: он работает и в разных предмет- 
ных областях, и в управлении проектами, и в работе программистов (как | 
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Определить 
проявление 
проблемы 


ЗЕЕ НЕЙ 


Собрать 
необходимую 
информацию 


| 


Выдвинуть гипотезу 
о причине проблемы 


| 


Проверить 
выдвинутую гипотезу 


























Нет Гипотеза 
подтвердилась? 
Да 
Нет 





Это первопричина? 


Да 


Сформировать 
рекомендации по 
устранению 














Рисунок 2.7.) — Алгоритм поиска первопричины дефекта 


На этом мы завершаем основную часть данной книги, посвящённую «тести- 
рованию в принципе». Далее будет рассмотрена автоматизация тестирования как 
совокупность техник, повышающих эффективность работы тестировщика по мно- 
гим показателям. 
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Раздел 3: автоматизация тестирования 


3.1. Выгоды и риски автоматизации 


3.1.1. Преимущества и недостатки автоматизации 


В разделе, посвящённом подробной классификации тестирования, мы 


кратко рассматривали, что собой представляет автоматизированное тестирова- 
ниез: это набор техник, подходов и инструментальных средств, позволяющий NC- 
ключить человека из выполнения некоторых задач в процессе тестирования. В таб- 
лице 2.3.673 был приведён краткий список преимуществ и недостатков автоматиза- 
ции, который сейчас мы рассмотрим подробно. 


Скорость выполнения тест-кейсов может в разы и на порядки превосходить 
возможности человека. Если представить, что человеку придётся вручную 
сверять несколько файлов размером в несколько десятков мегабайт каждый, 
оценка времени ручного выполнения становится пугающей: месяцы или даже 
годы. При этом 36 проверок, реализуемых в рамках дымового тестирования 
командными скриптами, выполняются менее чем за пять секунд и требуют 
от тестировщика только одного действия — запустить скрипт. 

Отсутствует влияние человеческого фактора в процессе выполнения тест- 
кейсов (усталости, невнимательности и т.д.). Продолжим пример из преды- 
дущего пункта: какова вероятность, что человек ошибётся, сравнивая (по- 
символьно!) даже два обычных текста размером в 100 страниц каждый? А 
если таких текстов 10? 20? И проверки нужно повторять раз за разом? Можно 
смело утверждать, что человек ошибётся гарантированно. Автоматика не 
ошибётся. 

Средства автоматизации способны выполнить тест-кейсы, в принципе непо- 
сильные для человека в силу своей сложности, скорости или иных факторов. 
И снова наш пример со сравнением больших текстов является актуальным: 
мы не можем позволить себе потратить годы, раз за разом выполняя крайне 
сложную рутинную операцию, в которой мы к тому же будем гарантированно 
допускать ошибки. Другим прекрасным примером непосильных для человека 
тест-кейсов является исследование производительности®, в рамках KOTO- 
рого необходимо с высокой скоростью выполнять определённые действия, а 
также фиксировать значения широкого набора параметров. Сможет ли чело- 
век, например, сто раз в секунду измерять и записывать объём оперативной 
памяти, занимаемой приложением? Нет. Автоматика сможет. 

Средства автоматизации способны собирать, сохранять, анализировать, аг- 
регировать и представлять в удобной для восприятия человеком форме ко- 
лоссальные объёмы данных. В нашем примере с дымовым тестированием 
«Конвертера файлов» объём данных, полученный в результате тестирова- 
ния, невелик — его вполне можно обработать вручную. Но если обратиться 
к реальным проектным ситуациям, журналы работы систем автоматизиро- 
ванного тестирования могут занимать десятки гигабайт по каждой итерации. 
Логично, что человек не в состоянии вручную проанализировать такие объ- 
ёмы данных, но правильно настроенная среда автоматизации сделает это 
сама, предоставив на выход аккуратные отчёты в 2-3 страницы, удобные гра- 
фики и таблицы, а также возможность погружаться в детали, переходя от аг- 
регированных данных к подробностям, если в этом возникнет необходи- 
мость. 

Средства автоматизации способны выполнять низкоуровневые действия с 
приложением, операционной системой, каналами передачи данных и т.д. В 
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одном из предыдущих пунктов мы упоминали такую задачу, как «сто раз в 
секунду измерить и записать объём оперативной памяти, занимаемой при- 
ложением». Подобная задача сбора информации об используемых приложе- 
нием ресурсах является классическим примером. Однако средства автома- 
тизации могут не только собирать подобную информацию, но и воздейство- 
вать на среду исполнения приложения или само приложение, эмулируя ти- 
пичные события (например, нехватку оперативной памяти или процессор- 
ного времени) и фиксируя реакцию приложения. Даже если у тестировщика 
будет достаточно квалификации, чтобы самостоятельно выполнить подоб- 
ные операции, ему всё равно понадобится то или иное инструментальное 
средство — так почему не решить эту задачу сразу на уровне автоматизации 
тестирования? 


Итак, с использованием автоматизации мы получаем возможность увеличить 
тестовое покрытиег'2 за счёт: 
• выполнения тест-кейсов, о которых раньше не стоило и думать; 
• многократного повторения тест-кейсов с разными входными данными; 
• высвобождения времени на создание новых тест-кейсов. 


Но всё ли так хорошо с автоматизацией? Увы, нет. Очень наглядно одну из 
серьёзных проблем можно представить рисунком 3.1.а: 


5 5 
Разработка = Т 
2 Ф 
с I 





Разработка и отладка 


Выпол- 
нение 





Рисунок 3.1.а — Соотношение времени разработки и выполнения тест-кейсов в 
ручном и автоматизированном тестировании 


В первую очередь следует осознать, что автоматизация не происходит сама 
по себе, не существует волшебной кнопки, нажатием которой решаются все про- 
блемы. Более того, с автоматизацией тестирования связана серия серьёзных не- 
достатков и рисков: 

• Необходимость наличия высококвалифицированного персонала в силу того 
факта, что автоматизация — это «проект внутри проекта» (со своими требо- 
ваниями, планами, кодом ит.д.). Даже если забыть на мгновение про «проект 
внутри проекта», техническая квалификация сотрудников, занимающихся ав- 
томатизацией, как правило, должна быть ощутимо выше, чем у их коллег, 
занимающихся ручным тестированием. 

e Разработка и сопровождение как самих автоматизированных тест-кейсов, так 
и всей необходимой инфраструктуры занимает очень много времени. Ситуа- 
ция усугубляется тем, что в некоторых случаях (при серьёзных изменениях в 
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проекте или в случае ошибок в стратегии) всю соответствующую работу при- 
ходится выполнять заново с нуля: в случае ощутимого изменения требова- 
ний, смены технологического домена, переработки интерфейсов (как пользо- 
вательских, так и программных) многие тест-кейсы становятся безнадёжно 
устаревшими и требуют создания заново. 

• Автоматизация требует более тщательного планирования и управления рис- 
ками, т.к. в противном случае проекту может быть нанесён серьёзный ущерб 
(см. предыдущий пункт про переделку с нуля всех наработок). 

• Коммерческие средства автоматизации стоят ощутимо дорого, а имеющиеся 
бесплатные аналоги не всегда позволяют эффективно решать поставленные 
задачи. И здесь мы снова вынуждены вернуться к вопросу ошибок в плани- 
ровании: если изначально набор технологий и средств автоматизации был 
выбран неверно, придётся не только переделывать всю работу, но и покупать 
новые средства автоматизации. 

• Средств автоматизации крайне много, что усложняет проблему выбора того 
или иного средства, затрудняет планирование и определение стратегии те- 
стирования, может повлечь за собой дополнительные временные и финан- 
совые затраты, а также необходимость обучения персонала или найма соот- 
ветствующих специалистов. 


Итак, автоматизация тестирования требует ощутимых инвестиций и сильно 
повышает проектные риски, а потому существуют специальные подходызез 364: 365 по 
оценке применимости и эффективности автоматизированного тестирования. Если 
выразить всю их суть очень кратко, то в первую очередь следует учесть: 

e Затраты времени на ручное выполнение тест-кейсов и на выполнение этих 
же тест-кейсов, но уже автоматизированных. Чем ощутимее разница, тем бо- 
лее выгодной представляется автоматизация. 

• Количество повторений выполнения одних и тех же тест-кейсов. Чем оно 
больше, тем больше времени мы сможем сэкономить за счёт автоматизации. 

e Затраты времени на отладку, обновление и поддержку автоматизированных 
тест-кейсов. Этот параметр сложнее всего оценить, и именно он представ- 
ляет наибольшую угрозу успеху автоматизации, потому здесь для проведе- 
ния оценки следует привлекать наиболее опытных специалистов. 

• Наличие в команде соответствующих специалистов и их рабочую загрузку. 
Автоматизацией занимаются самые квалифицированные сотрудники, кото- 
рые в это время не могут решать иные задачи. 





363 «Implementing Automated Software Testing — Continuously Track Progress апа Adjust Accordingly», Thom Garrett 


[http:/www.methodsandtools.com/archive/archive.php?id=94] 
«The ROI of Test Automation», Michael Kelly [https:/www.stickyminds.com/sites/default/files/presenta- 
tion/file/2013/04STRER_W12.pdf] 
365 «Cost Benefits Analysis of Test Automation», Douglas Hoffman [https:/www.cmcrossroads.com/sites/default/files/arti- 
cle/file/2014/Cost-Benefit%20Analysis%200f%20Test%20Automation.pdf] 


364 
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В качестве небольшого примера беглой оценки эффективности автоматиза- 
ции можно привести следующую формулуз: 


М: overall 
manual где 
.т4еортет ата support’ A 
automated 


Aeffect — коэффициент выгоды от использования автоматизации, 


Аегтесь = 


тип апа analyse 
N Ташотагеа 


М — планируемое количество билдов приложения; 


ТҮГЕП __ расчётное время разработки, выполнения и анализа результатов ручного тестиро- 


вания; 

тїт апа analyse 
automated 

тестирования; 
development and support 

Tautomated 

ного тестирования. 


— расчётное время выполнения и анализа результатов автоматизированного 


— расчётное время разработки и сопровождения автоматизирован- 


Чтобы нагляднее представить, как эта формула может помочь, изобразим 
график коэффициента выгоды автоматизации в зависимости от количества билдов 


(рисунок 3.1.5). Допустим, что в некотором проекте значения параметров таковы: 


Тотетай, = 30 часов на каждый билд 


тип апа analyse _ 5 йб А 
dutomated = 5 часов на каждый билд; 


таетеюртете апа support 


dutomåáted = 300 часов на весь проект. 


1.4 


1:2 


0.4 


Коэффициент выгодь 
о 
о 


0.2 


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 
Билд 


Рисунок 3.1.6 — Коэффициент выгоды автоматизации в зависимости от количе- 
ства билдов 


Как видно на рисунке 3.1.6, лишь к 12-му билду автоматизация окупит вложе- 
ния ис 13-го билда начнёт приносить пользу. И тем не менее существуют области, 
в которых автоматизация даёт ощутимый эффект почти сразу. Их рассмотрению 
посвящена следующая глава. 





366 «Introduction їо automation», Vitaliy Zhyrytskyy. 
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3.1.2. Области применения автоматизации 


Сначала мы ещё раз посмотрим на список задач, решить которые помогает 


автоматизация: 


e Выполнение тест-кейсов, непосильных человеку. 


Решение рутинных задач. 

Ускорение выполнения тестирования. 

Высвобождение человеческих ресурсов для интеллектуальной работы. 
Увеличение тестового покрытия. 

Улучшение кода за счёт увеличения тестового покрытия и применения спе- 


циальных техник автоматизации. 


Эти задачи чаще всего встречаются и проще всего решаются в следующих 
случаях (см. таблицу 3.1.а). 


Таблица 3.1.а — Случаи наибольшей применимости автоматизации 





Случай / задача 


Какую проблему решает автоматизация 





Регрессионное тестиро- 
вание“. 


Необходимость выполнять вручную тесты, количество которых 
неуклонно растёт с каждым билдом, но вся суть которых сводится к 
проверке того факта, что ранее работавшая функциональность про- 
должает работать корректно. 





Инсталляционное тести- 
рование3} и настройка 
тестового окружения. 


Множество часто повторяющихся рутинных операций по проверке 
работы инсталлятора, размещения файлов в файловой системе, 
содержимого конфигурационных файлов, реестра и т.д. Подготовка 
приложения в заданной среде и с заданными настройками для про- 
ведения основного тестирования. 





Конфигурационное тести- 
рование8} и тестирова- 
ние совместимости 8}. 


Выполнение одних и тех же тест-кейсов на большом множестве 
входных данных, под разными платформами и в разных условиях. 
Классический пример: есть файл настроек, в нём сто параметров, 
каждый может принимать сто значений: существует 100100 вариан- 
тов конфигурационного файла — все их нужно проверить. 





Использование комбина- 
торных техник тестирова- 
ния 94} (в т.ч. доменного 
тестирования ?}, 1239), 


Генерация комбинаций значений и многократное выполнение тест- 
кейсов с использованием этих сгенерированных комбинаций в каче- 
стве входных данных. 





Модульное тестирова- 
ние“), 


Проверка корректности работы атомарных участков кода и элемен- 
тарных взаимодействий таких участков кода — практически невы- 
полнимая для человека задача при условии, что нужно выполнить 
тысячи таких проверок и нигде не ошибиться. 





Интеграционное тестиро- 
вание". 


Глубокая проверка взаимодействия компонентов в ситуации, когда 
человеку почти нечего наблюдать, т.к. все представляющие инте- 

рес и подвергаемые тестированию процессы проходят на уровнях 
более глубоких, чем пользовательский интерфейс. 





Тестирование безопасно- 
сти{88}. 


Необходимость проверки прав доступа, паролей по умолчанию, от- 
крытых портов, уязвимостей текущих версий ПО и T.A., т.е. быстрое 
выполнение очень большого количества проверок, в процессе кото- 
рого нельзя что-то пропустить, забыть или «не так понять». 





Тестирование производи- 
тельности. 


Создание нагрузки с интенсивностью и точностью, недоступной че- 
ловеку. Сбор с высокой скоростью большого набора параметров ра- 
боты приложения. Анализ большого объёма данных из журналов 
работы системы автоматизации. 





Дымовой тест{7 8} для круп- 
ных систем. 


Выполнение при получении каждого билда большого количества до- 
статочно простых для автоматизации тест-кейсов. 





Приложения (или их ча- 
сти) без графического ин- 
терфейса. 








Проверка консольных приложений на больших наборах значений 
параметров командной строки (и их комбинаций). Проверка прило- 
жений и их компонентов, вообще не предназначенных для взаимо- 
действия с человеком (веб-сервисы, серверы, библиотеки и т.д.). 
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Длительные, рутинные, 
утомительные для чело- 
века и/или требующие по- 
вышенного внимания опе- 
рации. 


Проверки, требующие сравнения больших объёмов данных, высо- 
кой точности вычислений, обработки большого количества разме- 
щённых по всему дереву каталогов файлов, ощутимо большого вре- 
мени выполнения и т.д. Особенно, когда такие проверки повторя- 
ются очень часто. 





Проверка «внутренней 

функциональности» веб- 
приложений (ссылок, до- 
ступности страниц и т.д.). 


Автоматизация предельно рутинных действий (например, прове- 
рить все 30'000+ ссылок на предмет того, что все они ведут на pe- 
ально существующие страницы). Автоматизация здесь упрощается 
в силу стандартности задачи — существует много готовых решений. 





Стандартная, однотипная 
для многих проектов 
функциональность. 


Даже высокая сложность при первичной автоматизации в таком 
случае окупится за счёт простоты многократного использования по- 
лученных решений в разных проектах. 





«Технические задачи». 








Проверки корректности протоколирования, работы с базами дан- 
ных, корректности поиска, файловых операций, корректности фор- 
матов и содержимого генерируемых документов и т.д. 








С другой стороны, существуют случаи, в которых автоматизация, скорее 
всего, приведёт только к ухудшению ситуации. Вкратце — это все те области, где 
требуется человеческое мышление, а также некоторый перечень технологических 
областей. 

Чуть более подробно список выглядит так (таблица 3.1.0): 


Таблица 3.1.6 — Случаи наименьшей применимости автоматизации 





Случай / задача 


В чём проблема автоматизации 





Планирование 209. 





Разработка тест-кейсов!!!”. 





Написание отчётов о дефектах! 7. 





Анализ результатов тестирования и отчёт- 
ность203}, 


Компьютер пока не научился думать. 





Функциональность, которую нужно (доста- 
точно) проверить всего несколько раз. 





Тест-кейсы, которые нужно выполнить 
всего несколько раз (если человек может 
их выполнить). 


Затраты на автоматизацию не окупятся. 





Низкий уровень абстракции в имеющихся 
инструментах автоматизации. 


Придётся писать очень много кода, что не только 
сложно и долго, но и приводит к появлению множе- 
ства ошибок в самих тест-кейсах. 





Слабые возможности средства автомати- 
зации по протоколированию процесса те- 
стирования и сбору технических данных о 
приложении и окружении. 


Есть риск получить данные в виде «что-то где-то 
сломалось», что не помогает в диагностике про- 
блемы. 





Низкая стабильность требований. 


Придётся очень многое переделывать, что в случае 
автоматизации обходится дороже, чем в случае 
ручного тестирования. 





Сложные комбинации большого количе- 
ства технологий. 


Высокая сложность автоматизации, низкая надёж- 
ность тест-кейсов, высокая сложность оценки тру- 
дозатрат и прогнозирования рисков. 





Проблемы с планированием и ручным те- 
стированием. 


Автоматизация хаоса приводит к появлению авто- 
матизированного хаоса, но при этом ещё и требует 
трудозатрат. Сначала стоит решить имеющиеся 
проблемы, а потом включаться в автоматизацию. 





Нехватка времени и угроза срыва сроков 








Автоматизация не приносит мгновенных результа- 
тов. Поначалу она лишь потребляет ресурсы ко- 
манды (в том числе время). Также есть универ- 
сальный афоризм: «лучше руками протестировать 
хоть что-то, чем автоматизированно протестиро- 
вать ничего». 
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Области применения автоматизации 








Области тестирования, требующие оценки 
ситуации человеком (тестирование удоб- 
ства использования}, тестирование до- 
ступности? и т.д.). 








В принципе, можно разработать некие алгоритмы, 
оценивающие ситуацию так, как её мог бы оценить 
человек. Но на практике живой человек может сде- 
лать это быстрее, проще, надёжнее и дешевле. 








Вывод: стоит помнить, что эффект от автоматизации наступает не сразу и не 
всегда. Как и любой дорогостоящий инструмент, автоматизация при верном приме- 
нении может дать ощутимую выгоду, но при неверном принесёт лишь весьма ощу- 


тимые затраты. 
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3.2. Особенности автоматизированного тестирования 


3.2.1. Необходимые знания и навыки 


Во множестве источников, посвящённых основам автоматизации тестирова- 
ния, можно встретить схемы наподобие представленной на рисунке 3.2.а — то есть 
автоматизация тестирования представляет собой сочетание программирования и 
тестирования в разных масштабах (в зависимости от проекта и конкретных задач). 






Програм- 
мирование 


Тестиро- 
вание 









Автоматизация 
тестирования 






Програм- 
мирование 





Рисунок 3.2.а — Сочетание программирования и тестирования в автоматизации 
тестирования 


Отсюда следует простой вывод, что специалист по автоматизации тестиро- 
вания должен сочетать в себе навыки и умения как программиста, так и тестиров- 
щика. Но этим перечень не заканчивается: умение администрировать операцион- 
ные системы, сети, различные серверы, умение работать с базами данных, пони- 
мание мобильных платформ и т.д. — всё это может пригодиться. 

Но даже если остановиться только на навыках программирования и тестиро- 
вания, в автоматизации тоже есть свои особенности — набор технологий. В клас- 
сическом ручном тестировании развитие происходит постепенно и эволюционно — 
проходят годы и даже десятилетия между появлением новых подходов, завоёвы- 
вающих популярность. В программировании прогресс идёт чуть быстрее, но и там 
специалистов выручает согласованность и схожесть технологий. 

В автоматизации тестирования ситуация выглядит иначе: десятки и сотни 
технологий и подходов (как заимствованных из смежных дисциплин, так и уникаль- 
ных) появляются и исчезают очень стремительно. Количество инструментальных 
средств автоматизации тестирования уже исчисляется тысячами и продолжает 
неуклонно расти. 

Потому к списку навыков тестировщика можно смело добавить крайне высо- 
кую обучаемость и способность в предельно сжатые сроки самостоятельно найти, 
изучить, понять и начать применять на практике совершенно новую информацию 
из, возможно, ранее абсолютно незнакомой области. Звучит немного пугающе, но 
одно можно гарантировать: скучно не будет точно. 

О нескольких наиболее распространённых технологиях мы поговорим в 
главе «Технологии автоматизации тестирования» 28%. 
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3.2.2. Особенности тест-кейсов в автоматизации 


Часто (а в некоторых проектах и «как правило») автоматизации подвергаются 
тест-кейсы, изначально написанные простым человеческим языком (и, в принципе, 
пригодные для выполнения вручную) — т.е. обычные классические тест-кейсы, ко- 
торые мы уже рассматривали подробно в соответствующей главе“? 

И всё же есть несколько важных моментов, которые стоит учитывать при раз- 
работке (или доработке) тест-кейсов, предназначенных для дальнейшей автомати- 
зации. 

Главная проблема состоит в том, что компьютер — это не человек, и соот- 
ветствующие тест-кейсы не могут оперировать «интуитивно понятными описани- 
ями», а специалисты по автоматизации совершенно справедливо не хотят тратить 
время на то, чтобы дополнить такие тест-кейсы необходимыми для выполнения ав- 
томатизации техническими подробностями, — у них хватает собственных задач. 

Отсюда следует список рекомендаций по подготовке тест-кейсов к автомати- 
зации и непосредственно самой автоматизации: 

• Ожидаемый результат в автоматизированных тест-кейсах должен быть опи- 
сан предельно чётко с указанием конкретных признаков его корректности. 








Сравните: 
Плохо Хорошо 
7. Загружается стандартная страница по- 7. Загружается страница поиска: title = 
иска. «Search раде», присутствует форма с no- 


лями «три їуре="їехї"», «input 
type="submit" уаіие="Со!"», присутствует 
логотип «logo.jpg» и отсутствуют иные rpa- 
фические элементы («ітд»). 














• Поскольку тест-кейс может быть автоматизирован с использованием различ- 
ных инструментальных средств, следует описывать его, избегая специфиче- 
ских для того или иного инструментального средства решений. Сравните: 

















Плохо Хорошо 
1. Кликнуть по ссылке «Search». 1. Кликнуть по ссылке «Search». 
2. Использовать clickAndWait для синхро- 2. Дождаться завершения загрузки стра- 
низации тайминга. ницы. 





e В продолжение предыдущего пункта: тест-кейс может быть автоматизирован 
для выполнения под разными аппаратными и программными платформами, 
потому не стоит изначально прописывать в него что-то, характерное лишь 
для одной платформы. Сравните: 








Плохо Хорошо 
8. Отправить приложению сообщение 8. Передать фокус ввода любому из не 
WM_CLICK в любое из видимых окон. свёрнутых окон приложения (если таких 


нет — развернуть любое из окон). 
9. Проэмулировать событие «клик левой 
кнопкой мыши» для активного окна. 














• Одной из неожиданно проявляющихся проблем до сих пор является синхро- 
низация средства автоматизации и тестируемого приложения по времени: в 
случаях, когда для человека ситуация является понятной, средство автома- 
тизации тестирования может среагировать неверно, «не дождавшись» опре- 
делённого состояния тестируемого приложения. Это приводит к завершению 
неудачей тест-кейсов на корректно работающем приложении. Сравните: 
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Плохо Хорошо 
1. Кликнуть по ссылке «Ехрапа ааа». 1. Кликнуть по ссылке «Expand data». 
2. Выбрать из появившегося списка значе- | 2. Дождаться завершения загрузки данных 
ние «Unknown». в список «Extended даа» (select іа="ех- 
їепаеа ааїѓа"): список перейдёт в состояние 
enabled. 
3. Выбрать в списке «Extended data» значе- 
ние «Unknown». 

















Не стоит искушать специалиста по автоматизации на вписывание в код тест- 
кейса константных значений (т.н. «хардкодинг»). Если вы можете понятно 
описать словами значение и/или смысл некоей переменной, сделайте это. 
Сравните: 





Плохо Хорошо 
1. Открыть http://application/. 1. Открыть главную страницу приложения. 

















По возможности следует использовать наиболее универсальные способы 
взаимодействия с тестируемым приложением. Это значительно сократит 
время поддержки тест-кейсов в случае, если изменится набор технологий, с 
помощью которых реализовано приложение. Сравните: 





Плохо Хорошо 





8. Передать в поле «Search» набор собы- 8. Проэмулировать ввод значения поля 
тий WM_KEY_DOWN, {знак}, ММ КЕҮ ОР, | «Search» с клавиатуры (не годится вставка 
в результате чего в поле должен быть вве- | значения из буфера или прямое присваи- 
дён поисковый запрос. вание значения!) 














Автоматизированные тест-кейсы должны быть независимыми. Из любого 
правила бывают исключения, но в абсолютном большинстве случаев сле- 
дует предполагать, что мы не знаем, какие тест-кейсы будут выполнены до и 
после нашего тест-кейса. Сравните: 








Плохо Хорошо 
1. Из файла, созданного предыдущим те- 1. Перевести чек-бокс «Use stream buffer 
СТОМ... Не» в состояние сһескеа. 


2. Активировать процесс передачи данных 
(кликнуть по кнопке «Зай»). 
3. Из файла буферизации прочитать... 














Стоит помнить, что автоматизированный тест-кейс — это программа, и стоит 
учитывать хорошие практики программирования хотя бы на уровне отсут- 
ствия т.н. «магических значений», «хардкодинга» и тому подобного. Срав- 
ните: 











Плохо Хорошо 
if ($date_value == '2015.06.18') if ($date_value == дае(У.т.а’)) 
{ 
} «Магическое койстанта 
значение» 
if (РОМЕВ_ЧУЗЕВ == $status) 
if ($status = 42) { 






{ 
2 


Ошибка исправлена, к тому же 
} константа в сравнении нахо- 
дится слева от переменной 


Ошибка в выражении 
(= вместо ==) 
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Стоит внимательно изучать документацию по используемому средству авто- 
матизации, чтобы избежать ситуации, когда из-за неверно выбранной ко- 
манды тест-кейс становится ложно положительным, т.е. успешно проходит в 
ситуации, когда приложение работает неверно. 





| ‚ Так называемые ложно положительные тест-кейсы — едва ли не ca- 
| ‚ мое страшное, что бывает в автоматизации тестирования: они все- , 
‚ ляют в проектную команду ложную уверенность в том, что приложе- , 
ние работает корректно, т.е. фактически прячут дефекты, вместо | 





Поскольку для многих начинающих тестировщиков первым учебным сред- 
ством автоматизации тестирования является Selenium 10Ез57, приведём npn- 
мер с его использованием. Допустим, в некотором шаге тест-кейса нужно 
было проверить, что чек-бокс с Ч=сЬ выбран (checked). По какой-то причине 
тестировщик выбрал неверную команду, и сейчас на этом шаге проверятся, 
что чек-бокс позволяет изменять своё состояние (enabled, editable), а не что 
он выбран. 





Плохо (неверная команда) Хорошо (верная команда) 














уегіїуЕаќаріе | іа=ср уегіїуСһескеа | id=cb 









































И напоследок рассмотрим ошибку, которую по какой-то мистической причине 
совершает добрая половина начинающих автоматизаторов — это замена 
проверки действием и наоборот. Например, вместо проверки значения поля 
они изменяют значение. Или вместо изменения состояния чек-бокса прове- 
ряют его состояние. Здесь не будет примеров на «плохо/хорошо», т.к. хоро- 
шего варианта здесь нет — такого просто не должно быть, т.к. это — грубей- 
шая ошибка. 


Кратко подытожив рассмотренное, отметим, что тест-кейс, предназначенный 


для автоматизации, будет куда более похож на миниатюрное техническое задание 
по разработке небольшой программы, чем на описание корректного поведения те- 
стируемого приложения, понятное человеку. 


И ещё одна особенность автоматизированных тест-кейсов заслуживает от- 


дельного рассмотрения — это источники данных и способы их генерации. Для вы- 
полняемых вручную тест-кейсов эта проблема не столь актуальна, т.к. при выпол- 
нении 3—5—10 раз мы также вручную вполне можем подготовить нужное количество 
вариантов входных данных. Но если мы планируем выполнить тест-кейс 50—100 
500 раз с разными входными данными, вручную столько данных мы не подготовим. 
Источниками данных в такой ситуации могут стать: 


Случайные величины: случайные числа, случайные символы, случайные 
элементы из некоторого набора и т.д. 

Генерация (случайных) данных по алгоритму: случайные числа в заданном 
диапазоне, строки случайной длины из заданного диапазона из случайных 
символов из определённого набора (например, строка длиной от 10 до 100 
символов, состоящая только из букв), файлы с увеличивающимся по некоему 
правилу размером (например, 10 КБ, 100 КБ, 1000 КБ ит.д.). 





367 Selenium IDE. [https://www.selenium.dev/selenium-ide/] 
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• Получение данных из внешних источников: извлечение данных из базы дан- 
ных, обращение к некоему веб-сервису и т.д. 

• Собранные рабочие данные, т.е. данные, созданные реальными пользовате- 
лями в процессе их реальной работы (например, если бы мы захотели раз- 
работать собственный текстовый редактор, тысячи имеющихся у нас и наших 
коллег аос(х)-файлов были бы такими рабочими данными, на которых мы бы 
проводили тестирование). 

• Ручная генерация — да, она актуальная и для автоматизированных тест-кей- 
сов. Например, вручную создать по десять (да даже и по 50-100) корректных 
и некорректных е-тай-адресов получится куда быстрее, чем писать алгоритм 
их генерации. 


Применение некоторых из этих идей по генерации данных мы рассмотрим 
подробнее в следующей главе. 





Тестирование программного обеспечения. Базовый курс. © ЕРАМ Systems, 2015-2021 Стр: 265/298 


Технологии автоматизации тестирования 





3.2.3. Технологии автоматизации тестирования 


В данной главе мы рассмотрим несколько высокоуровневых технологий ав- 
томатизации тестирования, каждая из которых, в свою очередь, базируется на 
своём наборе технических решений (инструментальных средствах, языках про- 
граммирования, способах взаимодействия с тестируемым приложением ит.д.). 
Начнём с краткого обзора эволюции высокоуровневых технологий, при этом 
подчеркнув, что «старые» решения по-прежнему используются (или как компо- 
ненты «новых», или самостоятельно в отдельных случаях). 


Таблица 3.2.а — Эволюция высокоуровневых технологий автоматизации тестиро- 
вания 





№ 


Подход 


Суть 


Преимущества 


Недостатки 





Частные решения. 


Для решения каждой 
отдельной задачи 
пишется отдельная 
программа. 


Быстро, просто. 


Нет системности, 
много времени ухо- 
дит на поддержку. 
Почти невозможно 
повторное использо- 
вание. 




















ведение (Record & 
Playback). 





зации записывает 
действия тестиров- 
щика и может вос- 
произвести их, 
управляя тестируе- 
мым приложением. 





скорость создания 
тест-кейсов. 





2 | Тестирование под Из тест-кейса вовне Один и тот же тест- Логика тест-кейса по- 
управлением дан- выносятся входные кейс можно повто- прежнему строго 
ными} (DDT). данные и ожидае- рять многократно с определяется 

мые результаты. разными данными. внутри, а потому для 
её изменения тест- 
кейс надо переписы- 
вать. 

3 | Тестирование под Из тест-кейса вовне Концентрация на вы- | Сложность выполне- 
управлением ключе- | выносится описание | сокоуровневых дей- | ния низкоуровневых 
выми словами} его поведения. ствиях. Данные и операций. 

(КОТ). особенности поведе- 
ния хранятся вовне и 
могут быть изменены 
без изменения кода 
тест-кейса. 

4 | Использование Конструктор, позво- Мощность и гиб- Относительная 
фреймворков. ЛЯЮЩИЙ ИСПОЛЬЗО- КОСТЬ. сложность (особенно 

вать остальные под- — в создании 
ходы. фреймворка). 
5 | Запись и воспроиз- Средство автомати- | Простота, высокая Крайне низкое каче- 


ство, линейность, не- 
поддерживаемость 
тест-кейсов. Требу- 
ется серьёзная дора- 
ботка полученного 
кода. 
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6 | Тестирование под 
управлением пове- 
дением° (ВОТ). 


Развитие идей тести- 
рования под управ- 
лением данными и 
ключевыми словами. 
Отличие — в концен- 


Высокое удобство 
проверки высоко- 
уровневых пользова- 
тельских сценариев. 


Такие тест-кейсы 
пропускают большое 
количество функцио- 
нальных и нефункци- 
ональных дефектов, 


трации на бизнес- 
сценариях без вы- 
полнения мелких 
проверок. 


а потому должны 
быть дополнены 
классическими бо- 
лее низкоуровне- 
выми тест-кейсами. 























На текущем этапе развития тестирования представленные в таблице 3.2.а 
технологии иерархически можно изобразить следующей схемой (см. рисунок 3.2.6): 


Тестирование под управлением 
поведением 


Комбинация тестирование под управлением 
данными и ключевыми словами 


Тестирование под управлением 
ключевыми словами 


Тестирование под 
управлением данными 
Запись и 
воспроизведение 


Использование 
фреймворков 


Рисунок 3.2.6 — Иерархия технологий автоматизации тестирования 





Сейчас мы рассмотрим эти технологии подробнее и на примерах, но сначала 
стоит упомянуть один основополагающий подход, который находит применение 
практически в любой технологии автоматизации, — функциональную декомпози- 
ЦИЮ. 


Функциональная декомпозиция 






Функциональная декомпозиция (functional decompositions) — процесс 


mj В | 
‚ определения функции через её разделение на несколько низкоуровневых | 





Функциональная декомпозиция активно используется как в программирова- 
нии, так и в автоматизации тестирования с целью упрощения решения поставлен- 
ных задач и получения возможности повторного использования фрагментов кода 
для решения различных высокоуровневых задач. 

Рассмотрим пример (рисунок 3.2.с): легко заметить, что часть низкоуровне- 
вых действий (поиск и заполнение полей, поиск и нажатие кнопок) универсальна и 
может быть использована при решении других задач (например, регистрация, 
оформление заказа и т.д.). 





368 Functional decomposition. The process of defining lower-level functions апа sequencing relationships. [«System Engineering 
Fundamentals», Defense Acquisition University Press] 
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Произвести 


авторизацию 
Ввести имя Отправить Проверить 
Ввести пароль 
пользователя данные результат 
2 М На- Найти 
Найти Найти G 
жать над- 
поле кнопку 
кнопку пись 


Рисунок 3.2.с — Пример функциональной декомпозиции в программировании и те- 
стировании 





Найти 
поле 





Применение функциональной декомпозиции позволяет не только упростить 
процесс решения поставленных задач, но и избавиться от необходимости самосто- 
ятельной реализации действий на самом низком уровне, т.к. они, как правило, уже 
решены авторами соответствующих библиотек или фреймворков. 


Возвращаемся к технологиям автоматизации тестирования. 


Частные решения 


Иногда перед тестировщиком возникает уникальная (в том плане, что такой 
больше не будет) задача, для решения которой нет необходимости использовать 
мощные инструментальные средства, а достаточно написать небольшую про- 
грамму на любом из высокоуровневых языков программирования (Java, С#, РНР и 
т.д.) или даже воспользоваться возможностями командных файлов операционной 
системы или подобными тривиальными решениями. 

Ярчайшим примером такой задачи и её решения является автоматизация 
дымового тестирования нашего «Конвертера файлов» (код командных файлов для 
Windows и Linux приведён в соответствующем приложении?:'). Также сюда можно 
отнести задачи вида: 

• Подготовить базу данных, наполнив её тестовыми данными (например, до- 
бавить в систему миллион пользователей со случайными именами). 

• Подготовить файловую систему (например, создать структуру каталогов и 
набор файлов для выполнения тест-кейсов). 

• Перезапустить набор серверов и/или привести их в требуемое состояние. 


Удобство частных решений состоит в том, что их можно реализовать быстро, 
просто, «вот прямо сейчас». Но у них есть и огромный недостаток — это «кустарные 
решения», которыми может воспользоваться всего пара человек. И при появлении 
новой задачи, даже очень похожей на ранее решённую, скорее всего, придётся всё 
автоматизировать заново. 

Более подробно преимущества и недостатки частных решений в автомати- 
зации тестирования показаны в таблице 3.2.0. 
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Таблица 3.2.6 — Преимущества и недостатки частных решений в автоматизации 
тестирования 














Преимущества Недостатки 

• Быстрота и простота реализации. ® Отсутствие универсальности и, как след- 

® Возможность использования любых доступ- ствие, невозможность или крайняя слож- 
ных инструментов, которыми тестировщик ность повторного использования (адаптации 
умеет пользоваться. для решения других задач). 

• Эффект от использования наступает неза- ® Разрозненность и несогласованность реше- 
медлительно. ний между собой (разные подходы, техноло- 

® Возможность нахождения очень эффектив- гии, инструменты, принципы решения). 
ных решений в случае, когда основные ин- • Крайне высокая сложность развития, под- 
струменты, используемые на проекте для ав- держки и сопровождения таких решений 
томатизации тестирования, оказываются ма- (чаще всего, кроме самого автора никто во- 
лопригодными для выполнения данной от- обще не понимает, что и зачем было сде- 
дельной задачи. лано, и как оно работает). 

• Возможность быстрого создания и оценки ® Является признаком «кустарного производ- 
прототипов перед применением более тяже- ства», не приветствуется в промышленной 
ловесных решений. разработке программ. 








Тестирование под управлением данными (DDT) 


Обратите внимание, как много раз в командных файлах? повторяются 
строки, выполняющие одно и то же действие над набором файлов (и нам ещё по- 
везло, что файлов немного). Ведь куда логичнее было бы каким-то образом подго- 
товить список файлов и просто передать его на обработку. Это и будет тестирова- 
нием под управлением данными. В качестве примера приведём небольшой скрипт 
на РНР, который читает СЗ\-файл с тестовыми данными (именами сравниваемых 
файлов) и выполняет сравнение файлов. 


function сотраге 1ізі оЁ Е11ез ($Е11е міїһ сзу аафа) 


{ 





$data = Ғі1е ($Е11е міёһ сѕу даба); 
foreach ($data аз $line) 


{ 


$рагѕеа = ѕіг сѕу ($line); 


if (ма5 #і1е ($рагзеа[0]) === па5_Е11е ($рагѕеа[1])) { 

Ғі1е рої сопіепіѕ ('smoke_test.log', 

"ОК! File '".Ѕрагѕеа[0]."' was processed соггесё1у! \п"); 
} else { 

Ғі1е рої сопіепіѕ ('smoke_test.log', 

"ERROR! File '".брагзеа[0]."' was МОТ 





processed correctly!\n"); 


Пример С5\/-файла (первые две строки): 





Test ЕТАІОМ/«Мелкий» эталон М1М1251.& хе, О0Т/«Мелкий» файл в WIN1251.txt 
Test ЕТАІОМ/«Средний» эталон СР866.ЕхЕ,ОП0Т/«Средний» файл CP866.txt 














Теперь нам достаточно подготовить СЗ\У-файл с любым количеством имён 
сравниваемых файлов, а код тест-кейса не увеличится ни на байт. 
К другим типичным примерам использования тестирования под управлением 
данными относится: 
• Проверка авторизации и прав доступа на большом наборе имён пользовате- 
лей и паролей. 
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• Многократное заполнение полей форм разными данными и проверка реак- 
ции приложения. 

• Выполнение тест-кейса на основе данных, полученных с помощью комбина- 
торных техник (пример таких данных представлен в соответствующем при- 
ложении?°°)). 


Данные для рассматриваемого подхода к организации тест-кейсов могут по- 
ступать из файлов, баз данных и иных внешних источников или даже генериро- 
ваться в процессе выполнения тест-кейса (см. описание источников данных для ав- 
томатизированного тестирования). 

Преимущества и недостатки тестирования под управлением данными пока- 
заны в таблице 3.2.с. 


Таблица 3.2.с — Преимущества и недостатки тестирования под управлением дан- 
ными 











Преимущества Недостатки 

• Устранение избыточности кода тест-кейсов. • При изменении логики поведения тест-кейса 

• Удобное хранение и понятный человеку фор- его код всё равно придётся переписывать. 
мат данных. • При неудачно выбранном формате пред- 

• Возможность поручения генерации данных ставления данных резко снижается их понят- 
сотруднику, не имеющему навыков програм- ность для неподготовленного специалиста. 
мирования. • Необходимость использования технологий 

• Возможность использования одного и того генерации данных. 
же набора данных для выполнения разных • Высокая сложность кода тест-кейса в случае 
тест-кейсов. сложных неоднородных данных. 

• Возможность повторного использования • Риск неверной работы тест-кейсов в случае, 
набора данных для решения новых задач. когда несколько тест-кейсов работают с од- 

• Возможность использования одного и того ним и тем же набором данных, и он был из- 
же набора данных в одном и том же тест- менён таким образом, на который не были 
кейсе, но реализованном под разными плат- рассчитаны некоторые тест-кейсы. 
формами. • Слабые возможности по сбору данных в слу- 

чае обнаружения дефектов. 

• Качество тест-кейса зависит от профессио- 
нализма сотрудника, реализующего код тест- 
кейса. 











Тестирование под управлением ключевыми словами 


Логическим развитием идеи о вынесении вовне тест-кейса данных является 
вынесение вовне тест-кейса команд (описания действий). Разовьём только что по- 
казанный пример, добавив в С5\-файл ключевые слова, являющиеся описанием 
выполняемой проверки: 

e moved — файл отсутствует в каталоге-источнике и присутствует в каталоге- 
приёмнике; 

e intact — файл присутствует в каталоге-источнике и отсутствует в каталоге- 
приёмнике; 

e equals — содержимое файлов идентично. 


function execute_test ($ѕсепагіо) 
{ 
$data = file ($зсепагіо); 
foreach ($data as $line) 
{ 
$parsed = str csv ($line); 
switch ($parsed[0]) 
{ 
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// Проверка перемещения файла 

















case 'moved': 
if (1$ Е11е ($рагзеа[1])) &&(!1з Е11е ($рагзеа[2])) { 
file_put_contents ('smoke_test.log', 
"OK! '".Ѕрагѕеа[0]."' file was processed!\n"); 
pelse { 
file_put_contents ('smoke_test.log', 
"ERROR! '".5рагзеа[0]."' file was 
NOT processed!\n"); 
} 
break; 
// Проверка отсутствия перемещения файла 
сазе "intact"; 
if (!іѕ Ғі1е ($рагѕеа[1])) |1 (із #ғі1е ($рагѕеа[2])) { 
Ғі1е ро сопбепез ('smoke_test.log', 
"ОК! '".Ѕрагѕеа[0]."' file was ргосеззеа! \п"); 
} else { 
file_put_contents ('smoke_test.log', 
"ERROR! '".$parsed[0]."'" file was 
МОТ processed!\n"); 
} 
break; 
// Сравнение файлов 
сазе 'equals'!': 
if (ма5 #і1е ($рагзеа[1]) === па5_Е11е ($рагѕеа[2])) { 
Е11е ро сопбепез ('smoke_test.log', 
"ОК! File '".5$рагзеа[0]."' Маз 
processed correctly!\n"); 
} else { 
file_put_contents ('smoke_test.log', 
"ERROR! File '".брагзеа[0]."' Was 
NOT processed correctly!\n"); 
} 
break; 


Пример С5\/-файла (первые пять строк): 


moved, ТМ№/ «Мелкий» эталон ИМ1М1251.ЕхЕ, О0Т/ «Мелкий» файл в WIN1251.txt 


поуеа, ТМ/«Средний» этал 


їпїас®,Т\Ї/Карти 


ЕТА 


HKA. Jpg, 








equals, Test _ 





equals, Test 


ETA 








ОПТ/Картинка.)ра 





он СР866.іхі,ООТ/«Средний» файл СР866.іхі 


ОМ/«Мелкий» эталон М1М1251.ЕхЕ, ООТ/ «Мелкий» файл в WIN1251.txt 
ОМ/«Средний» эталон СР866.ЕхЕ, ООТ/«Средний» файл СР866.Е хе 





Ярчайшим примером инструментального средства автоматизации тестиро- 
вания, идеально следующего идеологии тестирования под управлением ключе- 
выми словами, является Selenium 10Ез67, в котором каждая операция тест-кейса 
описывается в виде: 








Действие (ключевое слово) 





Необязательный параметр 1 








Необязательный параметр 2 





Тестирование под управлением ключевыми словами стало тем переломным 
моментом, начиная с которого стало возможным привлечение к автоматизации те- 
стирования нетехнических специалистов. Согласитесь, что нет необходимости в 
знаниях программирования и тому подобных технологий, чтобы наполнять подоб- 
ные только что показанному С$\/-файлы или (что очень часто практикуется) XLSX- 


файлы. 
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Вторым естественным преимуществом тестирования под управлением клю- 
чевыми словами (хотя она вполне характерна и для тестирования под управлением 
данными) стала возможность использования различных инструментов одними и 
теми же наборами команд и данных. Так, например, ничто не мешает нам взять 
показанные С$\-файлы и написать новую логику их обработки не на РНР, ана С#, 
Java, Python или даже с использованием специализированных средств автомати- 
зации тестирования. 

Преимущества и недостатки тестирования под управлением ключевыми сло- 
вами показаны в таблице 3.2.4. 


Таблица 3.2.а — Преимущества и недостатки тестирования под управлением клю- 
чевыми словами 








Преимущества Недостатки 

® Максимальное устранение избыточности • Высокая сложность (и, возможно, длитель- 
кода тест-кейсов. ность) разработки. 

• Возможность построения мини-фреймвор- • Высокая вероятность наличия ошибок в коде 
ков, решающих широкий спектр задач. тест-кейса. 

• Повышение уровня абстракции тест-кейсов и | • Высокая сложность (или невозможность) вы- 
возможность их адаптации для работы с раз- полнения низкоуровневых операций, если 
ными техническими решениями. фреймворк не поддерживает соответствую- 

• Удобное хранение и понятный человеку фор- щие команды. 
мат данных и команд тест-кейса. • Эффект от использования данного подхода 

• Возможность поручения описания логики наступает далеко не сразу (сначала идёт 
тест-кейса сотруднику, не имеющему навы- длительный период разработки и отладки са- 
ков программирования. мих тест-кейсов и вспомогательной функцио- 

• Возможность повторного использования для нальности). 
решения новых задач. • Для реализации данного подхода требуется 

• Расширяемость (возможность добавления наличие высококвалифицированного персо- 
нового поведения тест-кейса на основе уже нала. 


Необходимо обучить персонал языку ключе- 
вых слов, используемых в тест-кейсах. 


реализованного поведения). 














Использование фреймворков 


Фреймворки автоматизации тестирования представляют собой не что иное, 
как успешно развившиеся и ставшие популярными решения, объединяющие в себе 
лучшие стороны тестирования под управлением данными, ключевыми словами и 
возможности реализации частных решений на высоком уровне абстракции. 

Фреймворков автоматизации тестирования очень много, они очень разные, 
но их объединяет несколько общих черт: 

• высокая абстракция кода (нет необходимости описывать каждое элементар- 
ное действие) с сохранением возможности выполнения низкоуровневых дей- 
ствий; 

e универсальность и переносимость используемых подходов; 

e достаточно высокое качество реализации (для популярных фреймворков). 
Как правило, каждый фреймворк специализируется на своём виде тестиро- 

вания, уровне тестирования, наборе технологий. Существуют фреймворки для мо- 
дульного тестирования (например, семейство хИпй), тестирования веб-приложений 
(например, семейство Selenium), тестирования мобильных приложений, тестирова- 
ния производительности и т.д. 

Существуют бесплатные и платные фреймворки, оформленные в виде биб- 
лиотек на некотором языке программирования или в виде привычных приложений 
с графическим интерфейсом, узко- и широко специализированные и т.д. 
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| ЕЗ ‚К сожалению, подробное описание даже одного фреймворка может по 
| : объёму быть сопоставимо со всем текстом данной книги. Но если вам nh- 





Преимущества и недостатки фреймворков автоматизации тестирования по- 
казаны в таблице 3.2.е. 


Таблица 3.2.е — Преимущества и недостатки фреймворков автоматизации тести- 
рования 

















Преимущества Недостатки 

® Широкое распространение. • Требуется время на изучение фреймворка. 

® Универсальность в рамках своего набора e В случае написания собственного фрейм- 
технологий. ворка де-факто получается новый проект по 

® Хорошая документация и большое сообще- разработке ПО. 
ство специалистов, с которыми можно про- ® Высокая сложность перехода на другой 
консультироваться. фреймворк. 

® Высокий уровень абстракции. ® В случае прекращения поддержки фрейм- 

• Наличие большого набора готовых решений ворка тест-кейсы рано или поздно придётся 
и описаний соответствующих лучших практик переписывать с использованием нового 
применения того или иного фреймворка для фреймворка. 
решения тех или иных задач. ® Высокий риск выбора неподходящего 

фреймворка. 





Запись и воспроизведение (Record & Playback) 


Технология записи и воспроизведения (Record & Playback) стала актуальной 
с появлением достаточно сложных средств автоматизации, обеспечивающих глу- 
бокое взаимодействие с тестируемым приложением и операционной системой. Ис- 
пользование этой технологии, как правило, сводится к следующим основным ша- 
гам: 
1. Тестировщик вручную выполняет тест-кейс, а средство автоматизации запи- 
сывает все его действия. 
2. Результаты записи представляются в виде кода на высокоуровневом языке 
программирования (в некоторых средствах — специально разработанном). 
3. Тестировщик редактирует полученный код. 
4. Готовый код автоматизированного тест-кейса выполняется для проведения 


тестирования в автоматизированном режиме. 










Возможно, вам приходилось записывать макросы в офисных приложе- 
‚ ниях. Это тоже технология записи и воспроизведения, только применён- 
ая для автоматизации решения офисных задач. | 


Сама технология при достаточно высокой сложности внутренней реализации 
очень проста в использовании и по самой своей сути, потому часто применяется 
для обучения начинающих специалистов по автоматизации тестирования. Её ос- 
новные преимущества и недостатки показаны в таблице 3.2.1. 





369 Selenium WebDriver Documentation [https://www.selenium.dev/documentation/en/webdriver/] 
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Таблица 3.2.1 — Преимущества и недостатки технологии записи и воспроизведения 








Преимущества Недостатки 
® Предельная простота освоения (достаточно • Линейность тест-кейсов: в записи не будет 
буквально нескольких минут, чтобы начать циклов, условий, вызовов функций и прочих 
использовать данную технологию). характерных для программирования и авто- 
• Быстрое создание «скелета тест-кейса» за матизации явлений. 
счёт записи ключевых действий с тестируе- ® Запись лишних действий (как просто ошибоч- 
мым приложением. ных случайных действий тестировщика с те- 
• Автоматический сбор технических данных о стируемым приложением, так и (во многих 
тестируемом приложении (идентификаторов случаях) переключений на другие приложе- 
и локаторов элементов, надписей, имён и ния и работы с ними). 
т.д.). • Так называемый «хардкодинг», т.е. запись 
• Автоматизация рутинных действий (заполне- внутрь кода тест-кейса конкретных значений, 
ния полей, нажатий на ссылки, кнопки и т.д.). что потребует ручной доработки для пере- 
е В отдельных случаях допускает использова- вода тест-кейса на технологию тестирования 
ние тестировщиками без навыков програм- под управлением данными. 
мирования. • Неудобные имена переменных, неудобное 


оформление кода тест-кейса, отсутствие 
комментариев и прочие недостатки, усложня- 
ющие поддержку и сопровождение тест- 
кейса в будущем. 

Низкая надёжность самих тест-кейсов в силу 
отсутствия обработки исключений, проверки 
условий и т.д. 














Таким образом, технология записи и воспроизведения не является универ- 
сальным средством на все случаи жизни и не может заменить ручную работу ПО 
написанию кода автоматизированных тест-кейсов, но в отдельных ситуациях может 
сильно ускорить решение простых рутинных задач. 


Тестирование под управлением поведением 


Рассмотренные выше технологии автоматизации максимально сфокусиро- 
ваны на технических аспектах поведения приложения и обладают общим недостат- 
ком: с их помощью сложно проверять высокоуровневые пользовательские сцена- 
рии (а именно в них и заинтересованы заказчики и конечные пользователи). Этот 
недостаток призвано исправить тестирование под управлением поведением, в ко- 
тором акцент делается не на отдельных технических деталях, а на общей работо- 
способности приложения при решении типичных пользовательских задач. 

Такой подход не только упрощает выполнение целого класса проверок, но и 
облегчает взаимодействие между разработчиками, тестировщиками, бизнес-ана- 
литиками и заказчиком, т.к. в основе подхода лежит очень простая формула «given- 
when-then»: 

e Given («имея, предполагая, при условии») описывает начальную ситуацию, B 
которой находится пользователь в контексте работы с приложением. 

e When («когда») описывает набор действий пользователя в данной ситуации. 

e Then («тогда») описывает ожидаемое поведение приложения. 


Рассмотрим на примере нашего «Конвертера файлов»: 

• При условии, что приложение запущено. 

• Когда я помещаю во входной каталог файл поддерживаемого размера и 
формата. 

e Тогда файл перемещается в выходной каталог, а текст внутри файла nepe- 
кодируется в ОТЕ-8. 
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Такой принцип описания проверок позволяет даже участникам проекта, не 
имеющим глубокой технической подготовки, принимать участие в разработке и ана- 
лизе тест-кейсов, а для специалистов по автоматизации упрощается создание кода 
автоматизированных тест-кейсов, т.к. такая форма является стандартной, единой 
и при этом предоставляет достаточно информации для написания высокоуровне- 
вых тест-кейсов. Существуют специальные технические решения (например, Већаї, 
JBehave, МВепауе, Cucumber), упрощающие реализацию тестирования под управ- 
лением поведением. 


Преимущества и недостатки тестирования под управлением поведением по- 
казаны в таблице 3.2.0. 


Таблица 3.2.0 — Преимущества и недостатки тестирования под управлением пове- 
дением 

















Преимущества Недостатки 
® Фокусировка на потребностях конечных e Высокоуровневые поведенческие тест-кейсы 
пользователей. пропускают много деталей, а потому могут 
® Упрощение сотрудничества между различ- не обнаружить часть проблем в приложении 
ными специалистами. или не предоставить необходимой для пони- 
• Простота и скорость создания и анализа мания обнаруженной проблемы информа- 
тест-кейсов (что, в свою очередь, повышает ции. 
полезный эффект автоматизации и снижает * В некоторых случаях информации, предо- 
накладные расходы). ставленной в поведенческом тест-кейсе, не- 
достаточно для его непосредственной авто- 
матизации. 








‚К классическим технологиям автоматизации тестирования также можно | 
‚ отнести разработку под управлением тестированием (Теѕі-дгіуеп Develop- _ 
ment, ТОО) с её принципом «красный, зелёный, улучшенный» (Вед-Сгееп- | 
‚ Refactor), разработку под управлением поведением (Веһћаміог-агіуеп Оеуе!- | 
opment), модульное тестирование (Unit Testing) и т.д. Но эти технологии | 
‚ уже находятся на границе тестирования и разработки приложений, потому _ 





ходят за рамки данной книги. 
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3.3. Автоматизация вне прямых задач тестирования 


На протяжении данного раздела мы рассматривали, как автоматизация мо- 
жет помочь в создании и выполнении тест-кейсов. Но все те же принципы можно 
перенести и на остальную работу тестировщика, в которой также бывают длитель- 
ные и утомительные задачи, рутинные задачи или задачи, требующие предельного 
внимания, но не связанные с интеллектуальной работой. Всё перечисленное также 
можно автоматизировать. 

Да, это требует технических знаний и первоначальных затрат сил и времени 
на реализацию, но в перспективе такой подход может экономить до нескольких ча- 
сов в день. К самым типичным решениям из данной области можно отнести: 

• Использование командных файлов для выполнения последовательностей 
операций — от копирования нескольких файлов из разных каталогов до раз- 
вёртывания тестового окружения. Даже в рамках многократно рассмотрен- 
ных примеров по тестированию «Конвертера файлов» запуск приложения че- 
рез командный файл, в котором указаны все необходимые параметры, из- 
бавляет от необходимости вводить их каждый раз вручную. 

e Генерация и оформление данных с использованием возможностей офисных 
приложений, баз данных, небольших программ на высокоуровневых языках 
программирования. Нет картины печальнее, чем тестировщик, руками нуме- 
рующий три сотни строк в таблице. 

• Подготовка и оформление технических разделов для отчётов. Можно тратить 
часы на скрупулёзное вычитывание журналов работы некоего средства ав- 
томатизации, а можно один раз написать скрипт, который будет за мгновение 
готовить документ с аккуратными таблицами и графиками, и останется 
только запускать этот скрипт и прикреплять результаты его работы к отчёту. 

• Управление своим рабочим местом: создание и проверка резервных копий, 
установка обновлений, очистка дисков от устаревших данных ит.д. ит.п. Ком- 
пьютер всё это может (и должен!) делать сам, без участия человека. 

• Сортировка и обработка почты. Даже раскладывание входящей корреспон- 
денции по подпапкам гарантированно занимаету вас несколько минут в день. 
Если предположить, что настройка специальных правил в вашем почтовом 
клиенте сэкономит вам полчаса в неделю, за год экономия составит при- 
мерно сутки. 

• Виртуализация как способ избавления от необходимости каждый раз уста- 
навливать и настраивать необходимый набор программ. Если у вас есть не- 
сколько заранее подготовленных виртуальных машин, их запуск займёт се- 
кунды. А в случае необходимости устранения сбоев разворачивание вирту- 
альной машины из резервной копии заменяет весь процесс установки и 
настройки с нуля операционной системы и всего необходимого программного 
обеспечения. 


Иными словами, автоматизация объективно облегчает жизнь любого ИТ-спе- 
циалиста, а также расширяет его кругозор, технические навыки и способствует про- 
фессиональному росту. 
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Раздел 4: приложения 


4.1. 
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Карьера тестировщика:” 








Основные навыки: 
1. Умение программировать на уровне, 
достаточном для создания автоматизированных 


2. Понимание специфических технологий и 
инструментальных средств, умение выбрать и 
применить их для решения поставленной задачи. 
3. Глубокое понимание принципов работы 


1. Умение планировать, реализовывать и 
оценивать результаты экспериментов. 
2. Умение оптимизировать тесты и тестовые 


3. Умение использовать вспомогательные 
программные средства, используемые проектной 
командой для автоматизации повседневных 


4. Понимание и умение использовать несколько 
высокоуровневых языков программирования, 
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тестирование 
Базы данных и 
язык SAL 
Отчётность о 
Коммуникативные оне Использование 
навыки кеу различных ОС 
тестирования 
Методы и Поиски Работа с 
методологии {—{ документирование Е—я багтрекинговыми 
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Виды тестирования 





Работа с системами 


Разработка тестов К— 
управления тестами 









































Основы Тестирование Работа с системами 
планирования в документации и К) управления 
тестировании требований требованиями 
Планирование Чтение 
своего рабочего Основы ЕЯ специальной 
тестирования 
времени литературы 
Функциональное тестирование 


Разработка и 
адаптация Cucumber 
инструментов ОВ ЖӨЕ. 
| Венауе 
Специальные 
технологии орт TDD 
программных средств 
Дополнительные навыки: 
Java 
Тестирование Selenium Android Driver 
мобильных с 
приложений 
р! Selenium iOS Driver Python сценарии. 
JavaScript 
Selenium 
Selenium DE т 
Web Driver VBScript 
Тестирование веб- = = задач. 
приложений и веб- я Soap lu Ruby 
сервисов Вык 
ЕБЕ Scala языков и технологий вёрстки. 
нуті mi 
4Тезї 
= JScript 
Тестирование SilkTest | |Testcompiete 
настольных XML 
приложений ОТР Autolt 
р HTML 
WSDL 
TestNG || JUnit 
Модульное ЗОАР 
пеотирование JMock NUnit SaL 
Инструменты 
автоматизирован- 
ного тестирования 
Тестирование Основы т 
производитель- автоматизации ЫК ме Программирование 
ности тестирования на Јауа/Стнеіс 





Основные навыки: 
1. Анализ технической документации. 

2. Создание чек-листов. 

3. Разработка тестов и тестовых сценариев. 
4. Поиски эффективное документирование 
обнаруженных дефектов. 

5. Формирование отдельных фрагментов отчётов 
о результатах тестирования 

6. Использование вспомогательных 
инструментальных средств. 

7. Понимание методов и видов тестирования, 
умение применять их адекватно ситуации. 


Дополнительные навыки: 
1. Умение вести деловое общение – «вживую», и 
использованием почты и иных средств 
коммуникации. 

2. Умение планировать рабочее время и 
‘оценивать трудозатраты. 

3. Понимание принципов работы компьютерных 
сетей. 

4. Понимание основ баз данных, умение писать 
тривиальные запросы. 

5. Умение работать с различными версиями ОС 
семейства Windows и "пі 








Дальнейший карьерный рост предполагает либо 
углубление в техническое направление и 
становление экспертом в некоторой области, 
либо переключение в область управления 
проектами или ресурсами. 





После успешного трудоустройства специалист в 
течение нескольких лет повышает свою 
квалификацию, приобретает всё более глубокий и 
обширный опыт, позволяющий как более 
эффективно выполнять свои прямые 
обязанности, так и рассматривать дальнейшие 
перспективы карьерного роста. 





Изучение автоматизации тестирования занимает 
от полугода до года. 


Предполагается, что к этому моменту соискатель 
уже изучил функциональное тестирование, а 
также обладает как минимум уверенными 
базовыми знаниями в области 
программирования. Автоматизация тестирования 
подразумевает программирование как часть 
повседневной деятельности. 


Особое внимание на этом этапе подготовки 
уделяется инструментальным средствам и 
специфическим технологиям. 





Наступает момент выбора: приступить к работе в 
качестве специалиста по функциональному 
тестированию, переключиться на изучение 
бизнес-анализа или продолжить изучение 
тестирования (в области автоматизации) 








Изучение функционального тестирования 
занимает от полугода до года. 


За это время необходимо приобрести полный 
набор технических и специализированных 
навыков, необходимых специалисту для начала 
работы тестировщиком 


Поскольку в тестирование приходит много людей 
без достаточной технической подготовки, 
соответствующим темам следует уделять особое 
внимание. 














Работа с офисными 
программами 








Формирование 
Английский язык — представления об 
1Т-специализации 














Базовая самоподготовка 





370 Полноразмерный вариант рисунка [http://svyatoslav.biz/wp-pics/testing_career_path.png] 


Знания и умения: 
1. Свободное владение Word, Excel. 

2. Свободное владение компьютером на уровне 
уверенного пользователя (умение устанавливать 
и настраивать ОС, сеть, необходимое ПО). 

3. Сформированное представление о работе 
тестировщика, желание заниматься именно этой 
работой. 

4. Знание английского на уровне беглого чтения 
англоязычной документации. 


Базовая самоподготовка может занимать разное 
время. В общем случае ей рекомендуется 
посвятить первые 2-3 курса университета. 


Успешная базовая самоподготовка позволяет 
пройти отбор на тренинг и усвоить программу 
тренинга 
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4.2. Комментарии к заданиям 





Задание 


Комментарий 





1.1.а® 


Ответ: около 2е+42 лет, т.е. примерно в 1.6бе+32 раза больше, чем 
текущий возраст Вселенной. 

Решение: (26 * 264 * 264) / (100'000'000 * 31536000"имерно секунд в году) = 
1.9904559029003934436313386045179е+42 лет. 





1.1.6) 


Для знакомства с широчайшим спектром терминологии тестирования 
рекомендуется внимательно изучить І50В Glossary: 
http:/www.istqb.org/downloads/glossary.html 





1.2.аи9 


Для очень примерной оценки своего уровня владения английским 
языком можно воспользоваться представленными в широком ассор- 
тименте онлайн-тестами, например вот этим: 
http://www.cambridgeenglish.org/test-your-english/ 





1.3.at2 


Пожалуйста, записывайте свои вопросы. Это не шутка. Сотнями ис- 
числяются случаи, когда на тренинге звучит что-то в стиле «Я жта- 
кое (!!!) хотел(а) спросить и забыл(а) ©». 





2.1.а(2® 


Если есть ощущение, что многое непонятно или забылось, исполь- 
зуйте как источник данные отсюда 
http://istqbexamcertification.com/what-are-the-software-development- 
models и попытайтесь сделать что-то наподобие собственного KOH- 
спекта. 





2.2.а81} 


Учли ли вы при составлении списка не только возможность ваших 
собственных недоработок, но и объективные факторы риска? Напри- 
мер, цена на некоторый товар выросла, товара не оказалось в нали- 
чии. Продумали ли вы, кто уполномочен принимать решение в ситуа- 
ции, когда «посовещаться со всеми» невозможно или слишком 
долго? 





2.2.0651 


При составлении списка вопросов рекомендуется опираться на две 
мысли: а) Как сделать продукт, максимально удовлетворяющий по- 
требности заказчика. б) Как реализовать и протестировать то, что 
требует заказчик. 

Игнорирование любого из этих пунктов может привести либо к созда- 
нию бесполезного продукта, либо к работе в ситуации неопределён- 
ности, когда по-прежнему не до конца ясно, что же разрабатывать и 
как это тестировать. 





2.2.654 


После того как вы выполнили это задание, проверьте себя с помо- 
щью материала главы «Типичные ошибки при анализе и тестирова- 
нии требований» 5%. Если вы обнаружили в своей работе какие-то из 
перечисленных там ошибок, исправьте их. 





2.2.459 


В продолжение теста на внимательность: заметили ли вы в тексте 
этой книги сколько-нибудь опечаток? Поверьте, они здесь есть. 





2.2.659 








По мере детализации набора требований ваши вопросы могут стано- 
виться всё более и более конкретными. Также помните, что стоит по- 
стоянно держать в голове всю общую картину требований, т.к. на 
низком уровне может проявиться проблема, затрагивающая обшир- 
ную часть требований и влияющая на весь проект. 
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2.3.а7“ 


После того, как у вас закончатся собственные идеи, вы можете при- 
бегнуть к небольшой хитрости: поищите в Интернете (и книгах, на ко- 
торые приведено множество ссылок) описание различных видов те- 
стирования, изучите области их применимости и дополните свой спи- 
сок на основе полученных знаний. 





2.4.а(113) 


После того, как вы составите список свойств качественных требова- 
ний, характерных для чек-листов, подумайте, какими свойствами 
должен обладать чек-лист, чтобы быть универсальным (т.е. чтобы 
его можно было использовать повторно на другом проекте). 





2.4.6116} 


На чём базировались ваши правки существующего чек-листа? Мо- 
жете ли вы аргументированно доказать преимущества предложен- 
ного вами варианта? 





2.4.0032 


Возможно, кто-то из ваших знакомых тестировщиков может рекомен- 
довать вам то или иное инструментальное средство, исходя из соб- 
ственного опыта. Если такого источника информации у вас нет, возь- 
мите список соответствующего ПО из Википедии и/или многочислен- 
ных обзоров в Интернете. 





2.4.439) 


Насколько приоритетным будет данный тест-кейс? Если он обнару- 
жит ошибку в приложении, какое значение важности вы ей присво- 
ите? (Примечание: сама идея «повторной конвертации» бессмыс- 
ленна, т.к. повторная конвертация файла, кодировка которого была 
приведена к UTF8, ничем по сути не отличается от просто первичной 
конвертации файла, изначально находящегося в этой кодировке. По- 
тому весь этот тест-кейс можно удалить, добавив в один из других 
тест-кейсов файл в кодировке UTF8 на вход конвертации.) 





2.4.6051 


Заметили ли вы отличия в рекомендациях по написанию тест-кейсов 
и вообще по проведению тестирования в проектах, реализуемых по 
«классическим» и гибким методологиям? 





2.4.1153) 


Если вы хорошо знаете какой-то язык программирования, можете 
написать программу, автоматизирующую представленные в данных 
командных файлах проверки. 





2.4.0155 


Можно ли сделать ваши автоматизированные проверки более уни- 
версальными? Можно ли вынести за пределы командных файлов 
наборы данных? А логику обработки данных? 





2.о.айт 








Ответ: в отчёте приведена ссылка на требование ДС-2.1, в котором 
сказано, что обработанные файлы помещаются в каталог-приёмник, 
а не перемещаются туда. Конечно, это дефект требований, но если 
подходить строго формально, то в требованиях нигде не сказано о 
перемещении обработанного файла, а потому отчёт о дефекте при- 
ложения может быть закрыт, хотя повторная обработка одного и того 
же файла явно противоречит здравому смыслу. Однако! Может выяс- 
ниться, что заказчик имел в виду, что приложение должно создавать 
в каталоге-приёмнике обработанные копии всех файлов из каталога- 
источника... и тут придётся многое переписывать, т.к. между «обра- 
ботать и переместить все файлы» и «обработать и скопировать все 
новые файлы, не затрагивая повторно никакие ранее обработанные 
файлы» есть существенная разница (вплоть до того, что придётся 
вычислять и хранить контрольные суммы всех файлов, т.к. нет ника- 
кой гарантии, что в каталоге-приёмнике какой-то файл не был заме- 
нён одноименным). 
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2.5.6189) 


Возможно, кто-то из ваших знакомых тестировщиков может рекомен- 
довать вам то или иное инструментальное средство, исходя из соб- 
ственного опыта. Если такого источника информации у вас нет, возь- 
мите список соответствующего ПО из Википедии и/или многочислен- 
ных обзоров в Интернете. 





2.6.а!? 


Для начала можно ознакомиться с этим примером: 
http://www.softwaretestingclass.com/wp- 
content/uploads/2013/01/Sample-Test-Plan-Template.pdf 





2.6.c{230 


Какие отвлекающие факторы снижали вашу производительность? 
Что у вас занимало больше всего времени (обдумывание тест-кей- 
сов, оформление или что-то иное)? Как вы считаете, повысилась или 
понизилась бы ваша производительность, если бы вы провели за 
изучением требований к проекту несколько часов или даже дней? 





2.7 .а{233} 


Ответ: потому, что здесь мы бы уже проверяли фактически взаимо- 
действие двух параметров. Это хорошая идея, но она выходит за 
рамки тестирования отдельной изолированной функциональности. 





2.7.003 


Самым эффективным способом доработки представленного списка 
является... программирование. Если вы достаточно хорошо знаете 
какой-нибудь язык программирования, напишите небольшую про- 
грамму, которая всего лишь будет получать из командной строки имя 
каталога и проверять его наличие и доступность для чтения. А затем 
протестируйте вашу программу и дополните представленный в за- 
даче список идеями, которые придут к вам в процессе тестирования. 





2.7.609 


В колонке «Наличие прав доступа» иногда отсутствуют значения, т.к. 
если каталог отсутствует, к нему неприменимо понятие «права до- 
ступа». Что касается лишних проверок, то, например, в строках 18 и 
22 пути приведены с «/» в качестве разделителя имён каталогов, что 
характерно для Linux, но не для Windows (хотя и сработает в боль- 
шинстве случаев). Такие проверки можно оставлять, но можно и уби- 
рать как низкоприоритетные. 





2.7 .00248) 


А если, кроме сложности, оценить также время на разработку тест- 
кейсов и проведение тестирования? А потом учесть необходимость 
повторять те же проверки многократно? 





2.7.0(249 


Можно использовать приведённый на рисунке 2.5.е“” пример описа- 
ния дефекта как шаблон для решения этого задания. 





2.7 252) 








Ответ: это плохое решение, т.к. теперь приложение будет пропускать 
имена каталогов вида «/////С:/аіг/пате/». Конечно, при проверке суще- 
ствования такой каталог не будет найден, но фильтрация данных всё 
равно нарушена. А вот имя «/» всё равно превратится в пустую 
строку. 
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4.3. Командные файлы для Windows и Linux, автоматизирую- 
щие выполнение дымового тестирования 





геп 








гет (чтобы в командах) 
сһср 65001 
гет Удаление файла жу > запуска 


del smoke_test.log /0 


rem Очистка входного каталога приложения: 


del ІМ\*.* /Q 


rem Запуск приложения: 


start php сопуегіег.рһр ТМ OUT сопуегіег.109 





гет Размещение тестовых Фай 


сору Теѕ ІМ\*.* ІМ > nul 


во входном каталоге прило» 


гет Таймаут в 10 секунд, чтобы прилож 


timeout 10 





ие успело обработать файлы: 


гет Остановка п рил ожения: 


Ғаѕккі11 /ІМ php.exe 









ления в каталоге файлов, 
ыть обр 


обработаны: 





ТЕ EXIST "ООТ\«Мелкий» файл в WIN1251.txt" ( 
echo ОК! '«Мелкий» файл в WIN1251.txt' file was processed! >> smoke test.log 
) ELSE ( Е 
echo ERROR! '«Мелкий» файл в WIN1251.txt' file was МОТ processed! >> ѕпоке іеѕі.1о9д 


) 


ТЕ EXIST "ООТ\«Средний» файл в CP866.txt" ( 
echo ОК! '«Средний» файл в CP866.txt' file was processed! >> ѕпоке _test.log 
) ELSE ( = 
echo ERROR! '«Средний» файл в CP866.txt' file was МОТ processed! >> ѕпоке іеѕі.1о9д 
) 


ТЕ EXIST "ООТ\«Крупный» файл в КОТЗВ. хе" ( 
echo ОК! '«Крупный» файл в KOI8R.txt' file was processed! >> ѕпоке +еѕіё.1од 
) ELSE ( Е 
echo ERROR! '«Крупный» файл в KOI8R.txt' file was МОТ processed! >> ѕпоке іеѕі.1о9д 
) 


ТЕ EXIST "ООТ\«Крупный» файл в міп-1251.һёт1" ( 
echo ОК! '«Крупный» файл в win-1251.html' file was processed! >> smoke _test.log 
) ELSE ( = 
echo ERROR! '«Крупный» файл в win-1251.html' file was МОТ processed! >> ѕпоке іеѕі.1о9д 
) 


ТЕ EXIST "ООТ\«Мелкий» файл в cp-866.html" ( 
echo ОК! '«Мелкий» файл в cp-866.html' file was processed! >> ѕпоке іеѕі.1о9д 
) ELSE ( 
echo ERROR! '«Мелкий» файл в cp-866.html' file was NOT processed! >> smoke_test.log 
) 


IF EXIST "ООТ\«Средний» файл в koi8-r.html" ( 
echo OK! '«Средний» файл в koi8-r.html' file was processed! >> smoke_test.log 
) ELSE ( 
echo ERROR! '«Средний» файл в koi8-r.html' file was NOT processed! >> smoke_test.log 
) 


IF EXIST "ООТ\«Средний» файл B WIN_1251.md" ( 
echo OK! '«Средний» файл в WIN_1251.md' file was processed! >> smoke_test.log 
) ELSE ( 
echo ERROR! '«Средний» файл в WIN_1251.md' file was NOT processed! >> smoke_test.log 
) 
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ТЕ EXIST "ООТ\«Крупный» файл в СР 866.та" ( 
echo ОК! ' «Крупный» файл в СР 866.пі'! file was processed! >> ѕпоке іеѕі.1о9д 
) ELSE ( 
echo ERROR! '«Крупный» файл в CP_866.md' file was NOT processed! >> smoke_test.log 
) 


IF EXIST "ООТ\«Мелкий» файл B KOI8_R.md" ( 
echo OK! '«Мелкий» файл в КОТ8 В.ш4' file was processed! >> smoke_test.log 
) ELSE ( 
echo ERROR! '«Мелкий» файл в KOI8_R.md' file was NOT processed! >> smoke_test.log 
) 


IF EXIST "ООТ\Слишком большой файл.х©" ( 
echo ERROR! 'Too big' file was processed! >> smoke_test.log 
) ELSE ( 
echo OK! 'Too big' file was NOT processed! >> smoke_test.log 
) 


IF EXIST "О0Т\Картинка.јро" ( 
echo ERROR! Picture file was processed! >> smoke_test.log 
) ELSE ( 
echo OK! Picture file was NOT processed! >> smoke_test.log 


) 


IF EXIST "ООТ\Картинка в виде TXT.txt" ( 
echo ОК! Picture file with TXT extension was processed! >> ѕпоке іеѕі.1о9д 
) ELSE ( 
echo ERROR! Picture file with TXT extension was NOT processed! >> smoke_test.log 


) 


IF EXIST "ООТ\Пустой файл.та" ( 
echo OK! Empty was processed! >> smoke_test.log 
) ELSE ( 
echo ERROR! Empty file was NOT processed! >> smoke_test.log 








echo. >> smoke_test.log 
echo Moving test: >> smoke_test.log 


IF NOT EXIST "IN\«Menknň» файл в WIN1251.txt" ( 
echo OK! '«Мелкий» файл в WIN1251.txt' file was moved! >> smoke_test.log 
) ELSE ( 
echo ERROR! '«Мелкий» файл в WIN1251.txt' file was NOT moved! >> smoke_test.log 
) 


IF NOT EXIST "ТМ\«Средний» файл в СР866.+хі" ( 
echo ОК! '«Средний» файл в СР866.іхі' file was moved! >> smoke_test.log 
) ELSE ( 
echo ERROR! '«Средний» файл в CP866.txt' file was NOT moved! >> smoke_test.log 
) 


ТЕ NOT EXIST "ТМ\«Крупный» файл в KOI8R.txt" ( 
echo OK! '«Крупный» файл в KOI8R.txt' file was moved! >> smoke_test.log 
) ELSE ( 
echo ERROR! '«Крупный» файл в KOI8R.txt' file was NOT moved! >> smoke_test.log 
) 


ТЕ NOT EXIST "ТМ\«Крупный» файл в win-1251.html" ( 
echo OK! '«Крупный» файл в win-1251.html' file was moved! >> smoke_test.log 
) ELSE ( 
echo ERROR! '«Крупный» файл в win-1251.html' file was NOT moved! >> smoke_test.log 
) 


ТЕ NOT EXIST "ТМ\«Мелкий» файл в cp-866.html" ( 
echo ОК! '«Мелкий» файл в cp-866.html' file was moved! >> smoke_test.log 
) ELSE ( 
echo ERROR! '«Мелкий» файл в cp-866.html' file was NOT moved! >> smoke_test.log 
) 


ТЕ NOT EXIST "ТМ\«Средний» файл в koi8-r.html" ( 
echo OK! '«Средний» файл в koi8-r.html' file was moved! >> smoke_test.log 
) ELSE ( 
echo ERROR! '«Средний» файл в koi8-r.html' file was NOT moved! >> smoke_test.log 
) 
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ТЕ МОТ EXIST "ІМ\«Средний» файл в МІМ 1251 .ма" ( 
echo ОК! ' «Средний» файл в ИТМ 1251.ш4' file was moved! >> smoke_test.log 
) ЕІЅЕ ( 
echo ERROR! '«Средний» файл в ИТМ 1251.ш4' file was МОТ moved! >> smoke_test.log 
) 


ТЕ МОТ EXIST "ТМ\«Крупный» файл в СР 866.та" ( 
echo ОК! ' «Крупный» файл в СР 866.ш4' file was moved! >> smoke_test.log 
) ЕІЅЕ ( 
echo ERROR! '«Крупный» файл в СР 866.пі'! file was МОТ moved! >> smoke_test.log 
) 


ТЕ МОТ EXIST "ІМ\«Мелкий» файл в КОІ8 К.та" ( 
echo ОК! '«Мелкий» файл в КОТ8 В.ш4' file was moved! >> smoke_test.log 
) ELSE ( 
echo ERROR! '«Мелкий» файл в КОТ8 R.md' file was NOT moved! >> smoke_test.log 
) 
IF NOT EXIST "ТМ\Слишком большой þaňzı.txt" ( 
echo ERROR! 'Too big' file was moved! >> smoke_test.log 
) ELSE ( 
echo OK! 'Too big' file was NOT moved! >> smoke_test.log 
) 


ТЕ NOT EXIST "ІМ\Картинка.јрд" ( 
echo ERROR! Picture file was moved! >> smoke_test.log 
) ELSE ( 
echo OK! Picture file was NOT moved! >> smoke_test.log 


) 


ТЕ NOT EXIST "ТМ\Картинка в виде TXT.txt" ( 
echo ОК! Picture file with TXT extension was moved! >> ѕпоке іеѕі.1о9д 
) ELSE ( 
echo ERROR! Picture file with TXT extension was NOT moved! >> smoke_test.log 






echo. >> smoke_test.log 
echo Comparing test: >> smoke_test.log 


:st1 

fc "Test ЕТАГОМ\ «Мелкий» эталон WIN1251.txt" "ООТ\«Мелкий» файл в WIN1251.txt" /B > nul 

IF ERRORLEVEL 1 СОТО stl_fail 

echo OK! File '«Мелкий» файл в WIN1251.txt' was processed correctly! >> smoke_test.log 

GOTO st2 

:501 Ғаі1 

echo ERROR! File '«Мелкий» файл в WIN1251.txt' was МОТ processed correctly! >> ѕпоке іеѕі.1о9д 


:512 

Ес "ТезЕ ЕТАГОМ\«Средний» эталон CP866.txt" "ООТ\«Средний» файл в CP866.txt" /В > nul 

ТЕ ERRORLEVEL 1 СОТО 512 _Ғаі1 

echo ОК! File ' «Средний» файл в CP866.txt' was processed correctly! >> ѕпоке іеѕі.1о9д 

СОТО st3 

:st2_fail 

echo ERROR! File '«Средний» файл в CP866.txt' was NOT processed correctly! >> smoke_test.log 


:st3 

Ес "Теѕі ЕТАГОМ\«Крупный» эталон КОТ8В.ЕхЕ" "ООТ\«Крупный» файл в KOI8R.txt" /В > nul 

ТЕ ERRORLEVEL 1 СОТО 53 Ғаі1 

echo ОК! File ' «Крупный» файл в KOI8R.txt' was processed correctly! >> ѕпоке іеѕі.1од 

СОТО 54 

:st3_fail 

echo ERROR! File '«Крупный» файл в KOI8R.txt' was NOT processed correctly! >> smoke_test.log 


:st4 

Ес "Теѕі ЕТАГОМ\«Крупный» эталон в win-1251.html" "ООТ\«Крупный» файл в win-1251.html" /B > nul 
ТЕ ERRORLEVEL 1 СОТО 564 Ғаі1 

echo ОК! File !' «Крупный» файл в win-1251.html' was processed correctly! >> ѕпоке іеѕі.1о9д 

СОТО st5 

:504 Ғаі1 

echo ERROR! File ' «Крупный» файл в win-1251.html' was МОТ processed correctly! >> ѕпоке іеѕі.1о9д 
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:st5 

Ес "Теѕі ЕТАГОМ\«Мелкий» эталон в cp-866.html" "ООТ\«Мелкий» файл в cp-866.html" /B > nul 

ТЕ ERRORLEVEL 1 СОТО $%5 Ғаі1 

echo ОК! File '«Мелкий» файл в cp-866.html' was processed correctly! >> ѕпоке іеѕі.1о9д 

СОТО st6 

:st5_fail 

echo ERROR! File '«Мелкий» файл в cp-866.html' was NOT processed correctly! >> smoke_test.log 


:st6 

fc "Тез®_ЕТАГОМ\ «Средний» эталон в koi8-r.html" "ООТ\«Средний» файл в koi8-r.html" /B > nul 
ТЕ ERRORLEVEL 1 СОТО $6 Ғаі1 

echo ОК! File '«Средний» файл в koi8-r.html' was processed correctly! >> ѕпоке іеѕі.1о9д 

СОТО st7 

:st6_fail 

echo ERROR! File '«Средний» файл в koi8-r.html' was NOT processed correctly! >> smoke_test.log 


:st7 

fc "Тез®_ЕТАГОМ\ «Средний» эталон в WIN_1251.md" "ООТ\«Средний» файл в WIN_1251.md" /B > nul 
ТЕ ERRORLEVEL 1 СОТО 567 Ғаі1 

echo ОК! File !' «Средний» файл в ИТМ 1251.ш4' was processed correctly! >> ѕпоке іеѕі.1о9д 

СОТО st8 

:st7_fail 

echo ERROR! File '«Средний» файл в WIN_1251.md' was NOT processed correctly! >> smoke_test.log 


:st8 

fc "Test ЕТАГОМ\«Крупный» эталон в CP_866.md" "ООТ\«Крупный» файл в CP_866.md" /B > nul 

IF ERRORLEVEL 1 GOTO st8_fail 

echo OK! File '«Крупный» файл в СР_866.ша' was processed correctly! >> smoke_test.log 

GOTO st9 

:st8_fail 

echo ERROR! File '«Крупный» файл в СР_866.ша' was NOT processed correctly! >> smoke_test.log 


:st9 

fc "Test ЕТАГОМ\ «Мелкий» эталон в KOI8_R.md" "ООТ\«Мелкий» файл в KOI8 В.ша" /В > nul 

IF ERRORLEVEL 1 СОТО st9_ fail 

echo OK! File '«Мелкий» файл в KOI8_R.md' was processed correctly! >> smoke_test.log 

GOTO st10 

:st9_fail 

echo ERROR! File '«Мелкий» файл в KOI8_R.md' was NOT processed correctly! >> smoke_test.log 


:st10 

fc "Test ЕТАГОМ\Пустой файл.ша" "ООТ\Пустой файл.ша" /В > nul 

ТЕ ERRORLEVEL 1 СОТО $10 Ғаі1 

echo ОК! File 'Пустой файл.шЧ' was processed correctly! >> ѕпоке іеѕі.1о9д 

СОТО епа 

:5+10 Ғаі1 

echo ERROR! File 'Пустой файл.ша' was МОТ processed correctly! >> ѕпоке іеѕі.1о9д 


:епа 


echo WARNING! File 'Картинка в виде TXT.txt' has МО etalon decision, and it's ОК for this file to 
be corrupted. >> smoke_test.log 


Bash-ckpnnT для Linux 
#!/bin/bash 


# Удаление файла журнала 


rm -f smoke_test.log 





# Очистка входного ка 


rm -r -f ТМ/* 





Hg ж нн 





php converter.php ТМ OUT сопуегіег.1од & 





# Размещен 


ср Теѕі ТМ/* ІМ/ 


те тестовых файлов во входном 





# Таймаут в 10 секунд, чтобы приложение успело аботать файлы: 


sleep 10 





# Остановка приложения: 


killall php 
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и 





оявле Ія ов, кс не до ы быть оор 


+ 


echo "Processing test:" >> smoke_test.log 


if [ -f "OUT/«Menknň» файл в WIN1251.txt" ] 
then 
echo "ОК! '«Мелкий» файл в WIN1251.txt' file was processed!" >> smoke_test.log 
else 
echo "ERROR! '«Мелкий» файл в WIN1251.txt' file was NOT processed!" >> smoke_test.log 
fi 


if [ -f "ООТ/«Средний» файл в CP866.txt" ] 
then 
echo "ОК! '«Средний» файл в CP866.txt' file was processed!" >> smoke_test.log 
else 
echo "ERROR! '«Средний» файл в CP866.txt' file was NOT processed!" >> smoke_test.log 
fi 


if [ -f "ООТ/«Крупный» файл в KOI8R.txt" ] 
then 
echo "ОК! '«Крупный» файл в KOI8R.txt' file was processed!" >> smoke_test.log 
else 
echo "ERROR! '«Крупный» файл в KOI8R.txt' file was NOT processed!" >> smoke_test.log 
fi 


if [ -f "ООТ/«Крупный» файл в win-1251.html" ] 
then 
echo "ОК! '«Крупный» файл в win-1251.html' file was processed!" >> smoke_test.log 
else 
echo "ERROR! '«Крупный» файл в win-1251.html' file was NOT processed!" >> smoke_test.log 
fi 


if [ -f "ООТ/«Мелкий» файл в cp-866.html" ] 
then 
echo "ОК! '«Мелкий» файл в cp-866.html' file was processed!" >> smoke_test.log 
else 
echo "ERROR! '«Мелкий» файл в cp-866.html' file was NOT processed!" >> smoke_test.log 
fi 


if [ -f "ООТ/«Средний» файл в koi8-r.html" ] 
then 
echo "ОК! '«Средний» файл в koi8-r.html' file was processed!" >> smoke_test.log 
else 
echo "ERROR! '«Средний» файл в koi8-r.html' file was NOT processed!" >> smoke_test.log 
fi 


if [ -f "ООТ/«Средний» файл в ИТМ 1251.ма" ] 
then 
echo "ОК! '«Средний» файл в WIN_1251.md' file was processed!" >> smoke_test.log 
else 
echo "ERROR! '«Средний» файл в WIN_1251.md' file was NOT processed!" >> smoke_test.log 
fi 


if [ -f "ООТ/«Крупный» файл в CP_866.md" ] 
then 
echo "ОК! '«Крупный» файл в CP_866.md' file was processed!" >> smoke_test.log 
else 
echo "ERROR! '«Крупный» файл в CP_866.md' file was NOT processed!" >> smoke_test.log 
fi 


if [ -f "OUT/«Menknň» файл в KOI8_R.md" ] 
then 
echo "OK! '«Мелкий» файл в KOI8_R.md' file was processed!" >> smoke_test.log 
else 
echo "ERROR! '«Мелкий» файл в KOI8_R.md' file was NOT processed!" >> smoke_test.log 
fi 


if [ -f "ООТ/Слишком большой файл.іхі" ] 


then 

echo "ERROR! 'Too big' file was processed!" >> smoke_test.log 
else 

echo "OK! 'Too big' file was NOT processed!" >> smoke_test.log 
fi 
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if [ -f "ООТ/Картинка.)рд" ] 


then 

echo "ERROR! Picture file was processed!" >> smoke_test.log 
else 

echo "OK! Picture file was NOT processed!" >> smoke_test.log 
fi 


if [ -f "ООТ/Картинка в виде TXT.txt" ] 
then 
echo "OK! Picture file with TXT extension was processed!" >> smoke_test.log 
else 
echo "ERROR! Picture file with TXT extension was NOT processed!" >> smoke_test.log 
fi 


if [ -Е "ООТ/Пустой файл.та" ] 


then 
echo "OK! Empty file was processed!" >> smoke_test.log 
else 
echo "ERROR! Empty file was NOT processed!" >> smoke_test.log 


Ғі 





не 


echo "" >> smoke_test.log 
echo "Moving test:" >> smoke_test.log 


if [ ! -f "ІМ/«Мелкий» файл в WIN1251.txt" ] 
then 
echo "OK! '«Мелкий» файл в WIN1251.txt' file was moved!" >> smoke_test.log 
else 
echo "ERROR! '«Мелкий» файл в WIN1251.txt' file was NOT moved!" >> smoke_test.log 
fi 


if [ ! -f "ТМ/ «Средний» файл в CP866.txt" ] 
then 
echo "OK! '«Средний» файл в CP866.txt' file was moved!" >> smoke_test.log 
else 
echo "ERROR! '«Средний» файл в CP866.txt' file was NOT moved!" >> smoke_test.log 
fi 


if [ ! -f "ТМ/ «Крупный» файл в KOI8R.txt" ] 
then 
echo "ОК! '«Крупный» файл в KOI8R.txt' file was moved!" >> smoke_test.log 
else 
echo "ERROR! '«Крупный» файл в KOI8R.txt' file was NOT moved!" >> smoke_test.log 
fi 


if [ ! -f "ТМ/ «Крупный» файл в win-1251.html" ] 
then 
echo "ОК! '«Крупный» файл в win-1251.html' file was moved!" >> smoke_test.log 
else 
echo "ERROR! '«Крупный» файл в win-1251.html' file was NOT moved!" >> smoke_test.log 
fi 


if [ ! -f "ІМ/«Мелкий» файл в cp-866.html" ] 
then 
echo "OK! '«Мелкий» файл в cp-866.html' file was moved!" >> smoke_test.log 
else 
echo "ERROR! '«Мелкий» файл в cp-866.html' file was NOT moved!" >> smoke_test.log 
fi 


if [ ! -f "ТМ/ «Средний» файл в koi8-r.html" ] 
then 
echo "ОК! '«Средний» файл в koi8-r.html' file was moved!" >> smoke_test.log 
else 
echo "ERROR! '«Средний» файл в koi8-r.html' file was NOT moved!" >> smoke_test.log 
fi 


if [ ! -f "ІМ/«Средний» файл в WIN_1251.md" ] 
then 
echo "ОК! '«Средний» файл в WIN_1251.md' file was moved!" >> smoke_test.log 
else 
echo "ERROR! '«Средний» файл в WIN_1251.md' file was NOT moved!" >> smoke_test.log 
fi 
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if [! 
then 
echo 
else 
echo 
fi 


if [! 
then 
echo 
else 
echo 
fi 


if [! 
then 
echo 
else 
echo 
fi 


if [! 
then 
echo 
else 
echo 
fi 


if [! 
then 
echo 
else 
echo 
fi 


if [! 

then 
echo 

else 


-f "ТМ/«Крупный» файл в CP_866.md" ] 
"ОК! '«Крупный» файл в СР 866.ш4' file was moved!" >> smoke_test.log 


"ERROR! '«Крупный» файл в СР 866.шА' file was МОТ moved!" >> smoke_test.log 


-f "ІМ/ «Мелкий» файл в KOI8_R.md" ] 
"ОК! '«Мелкий» файл в КОТ8 В.шА' file was moved!" >> smoke_test.log 


"ERROR! '«Мелкий» файл в КОІ8 R.md' file was МОТ moved!" >> smoke_test.log 


-f "ІМ/Слишком большой файл. хе" ] 
"ERROR! 'Тоо big' file was moved!" >> smoke_test.log 


"OK! 'Too big' file was NOT moved!" >> smoke_test.log 


-f "ІМ/Картинка.јрд" ] 
"ERROR! Picture file was moved!" >> smoke_test.log 


"OK! Picture file was NOT moved!" >> smoke_test.log 


=f "ІМ/Картинка в виде ТХТ.ёхі" ] 
"ОК! Picture file with TXT extension was moved!" >> smoke_test.log 


"ERROR! Picture file with TXT extension was NOT moved!" >> smoke_test.log 


-f "ІМ/Пустой файл.та" ] 


"ОК! Empty file was moved!" >> smoke_test.log 


"ERROR! Empty file was NOT moved!" >> smoke_test.log 











боты прилс ния 


есһо "" >> smoke_test.log 











echo "Comparing test:" >> smoke_test.log 


if cmp 
then 
echo 
else 
echo 
fi 


if cmp 
then 
echo 
else 
echo 
fi 


if cmp 
then 
echo 
else 
echo 
fi 


-s "ТезЕ ЕТАГОМ/«Мелкий» эталон WIN1251.txt" "ООТ/«Мелкий» файл в WIN1251.txt" 
"ОК! File '«Мелкий» файл в WIN1251.txt' was processed correctly!" >> smoke_test.log 


"ERROR! File '«Мелкий» файл в WIN1251.txt' was NOT processed correctly!" >> smoke_test.log 


-s "ТезЕ ЕТАГОМ/«Средний» эталон CP866.txt" "ООТ/«Средний» файл CP866.txt" 
"ОК! File '«Средний» файл СР866.ЕхЕ' was processed correctly!" >> smoke_test.log 


"ERROR! File '«Средний» файл СР866.ЕхЕ' was МОТ processed correctly!" >> smoke_test.log 


-s "ТезЕ ЕТАГОМ/«Крупный» эталон KOI8R.txt" "ООТ/«Крупный» файл KOI8SR.txt" 
"OK! File '«Крупный» файл KOI8R.txt' was processed correctly!" >> smoke_test.log 


"ERROR! File '«Крупный» файл KOI8R.txt' was NOT processed correctly!" >> smoke_test.log 
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if стр -s "Теѕі ЕТАГОМ/«Крупный» файл в win-1251.html" "ООТ/«Крупный» файл в win-1251.html" 
then 

echo "OK! File '«Крупный» файл в win-1251.html' was processed correctly!" >> smoke_test.log 
else 

echo "ERROR! File '«Крупный» файл в win-1251.html' was NOT processed correctly!" >> smoke_test.log 
fi 


if cmp -s "Test ЕТАГОМ/«Мелкий» эталон в cp-866.html" "ООТ/«Мелкий» файл в cp-866.html" 
then 
echo "OK! File '«Мелкий» файл в cp-866.html' was processed correctly!" >> smoke_test.log 
else 
echo "ERROR! File '«Мелкий» файл в cp-866.html' was NOT processed correctly!" >> smoke_test.log 
fi 


if cmp -s "Test ЕТАГОМ/«Средний» эталон в koi8-r.html" "ООТ/«Средний» файл в koi8-r.html" 
then 
echo "OK! File '«Средний» файл в koi8-r.html' was processed correctly!" >> smoke_test.log 
else 
echo "ERROR! File '«Средний» файл в koi8-r.html' was NOT processed correctly!" >> smoke_test.log 
fi 


if cmp -s "Test ЕТАГОМ/«Средний» эталон в WIN_1251.md" "ООТ/«Средний» файл в WIN_1251.md" 
then 
echo "OK! File '«Средний» файл в WIN_1251.md' was processed correctly!" >> smoke_test.log 
else 
echo "ERROR! File '«Средний» файл в WIN_1251.md' was NOT processed correctly!" >> smoke_test.log 
fi 


if cmp -s "Теѕі ЕТАГОМ/«Крупный» эталон в CP_866.md" "ООТ/«Крупный» файл в CP_866.md" 
then 
echo "OK! File '«Крупный» файл в СР_866.ша' was processed correctly!" >> smoke_test.log 
else 
echo "ERROR! File '«Крупный» файл в СР_866.ша' was NOT processed correctly!" >> smoke_test.log 
fi 


if cmp -s "Test ЕТАГОМ/«Мелкий» эталон в KOI8_R.md" "OUT/«Menknň» файл в KOI8_R.md" 
then 
echo "OK! File '«Мелкий» файл в KOI8_R.md' was processed correctly!" >> smoke_test.log 
else 
echo "ERROR! File '«Мелкий» файл в КОТ8 В.ш4' was NOT processed correctly!" >> smoke_test.log 
fi 


if cmp -s "Test ЕТАГОМ/Пустой файл.ш4" "ООТ/Пустой файл.ша" 
then 
echo "OK! File 'Пустой файл.шЧ' was processed correctly!" >> smoke_test.log 
else 
echo "ERROR! File 'Пустой файл.шЧ' was NOT processed correctly!" >> smoke_test.log 
fi 


echo "WARNING! File 'Картинка в виде TXT.txt' has NO etalon decision, and it's ОК for this file to 
be corrupted." >> smoke_test.log 


Пример результатов выполнения (на одном из первых билдов, CO- 
держащих множество дефектов) 


Processing test: 

ОК! '«Мелкий» файл в WIN1251.txt' file was processed! 
ОК! '«Средний» файл в CP866.txt' file was processed! 
ОК! '«Крупный» файл в KOI8R.txt' file was processed! 
ОК! '«Крупный» файл в win-1251.html' file was processed! 
ОК! '«Мелкий» файл в cp-866.html' file was processed! 
ОК! '«Средний» файл в koi8-r.html' file was processed! 
ОК! '«Средний» файл в WIN_1251.md' file was processed! 
ОК! '«Крупный» файл в CP_866.md' file was processed! 
ОК! '«Мелкий» файл в KOI8_R.md' file was processed! 
OK! 'Too big' file was NOT processed! 

OK! Picture file was NOT processed! 

OK! Picture file with TXT extension was processed! 


Moving test: 

ERROR! '«Мелкий» файл в WIN1251.txt' file was NOT moved! 
ERROR! '«Средний» файл в CP866.txt' file was NOT moved! 
ERROR! '«Крупный» файл в KOI8R.txt' file was NOT moved! 
ERROR! '«Крупный» файл в win-1251.html' file was NOT moved! 
ERROR! '«Мелкий» файл в cp-866.html' file was NOT moved! 
ERROR! '«Средний» файл в Коі8-г.Һіт1' file was NOT moved! 
ERROR! '«Средний» файл в WIN_1251.md' file was NOT moved! 
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ERROR! '«Крупный» файл в СР 866.ш4' file was МОТ moved! 
ERROR! '«Мелкий» файл в КОТ8 В.ш4' file was МОТ moved! 
ОК! 'Тоо big' file was МОТ moved! 

OK! Picture file was NOT moved! 

ERROR! Picture file with TXT extension was NOT moved! 


Comparing test: 

ERROR! File '«Мелкий» файл в WIN1251.txt' was NOT processed correctly! 
ERROR! File '«Средний» файл в CP866.txt' was NOT processed correctly! 
ERROR! File '«Крупный» файл в KOI8R.txt' was NOT processed correctly! 
ERROR! File '«Крупный» файл в win-1251.html' was NOT processed correctly! 
ERROR! File '«Мелкий» файл в cp-866.html' was NOT processed correctly! 
ERROR! File '«Средний» файл в koi8-r.html' was NOT processed correctly! 
ERROR! File '«Средний» файл в WIN_1251.md' was NOT processed correctly! 
ERROR! File '«Крупный» файл в CP_866.md' was NOT processed correctly! 
ERROR! File '«Мелкий» файл в KOI8_R.md' was NOT processed correctly! 

OK! File 'Пустой файл.шА' was processed correctly! 

WARNING! File 'Картинка в виде TXT.txt' has NO etalon decision, and it's OK for this file to be 
corrupted. 
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№ Расположение / Существо- Наличие прав доступа Семейство Коди- 
длина / значение вание ос ровки 
| комбинация 
символов / заре- 
зервированное 
или свободное 
1. ХА Да К каталогу и его содержи- | Windows 64 ОТЕ8 
мому bit 
2. smb://host/dir HeT Linux 32 bit UTF16 
3. „ЛАТ Да Ни к каталогу, ни K ero co- | Linux 64 bit OEM 
держимому 
4. [257 байт только Да Только к каталогу Windows 64 | ОЕМ 
для Windows] bit 
5. smb://host/dir/ Да К каталогу и его содержи- | Linux 64 bit ОТЕ8 
мому 
6. пи! Да Ни к каталогу, ни к его co- | Windows 64 | ОЕМ 
держимому bit 
7. \\ HeT Linux 64 bit UTF16 
8. /dir Да Ни к каталогу, ни K ero co- | Linux 32 bit ОЕМ 
держимому 
9. ./dir/ HeT Linux 32 bit OEM 
10. ./dir HeT К каталогу и ero содержи- | Linux 64 bit UTF8 
MOMY 
11. smb://host/dir Да Только к каталогу Linux 64 bit UTF8 
12. \\hostì\dir\ Да К каталогу и его содержи- | Linux 32 bit ОТЕ8 
мому 
13. host:/dir HeT Windows 32 UTF8 
bit 
14. Adin HeT Windows 64 UTF8 
bit 
15. [0 символов] HeT Windows 32 UTF16 
bit 
16. [4097 байт только | HeT Linux 32 bit UTF16 
ana Linux] 
17. „Adin HeT Windows 32 UTF16 
bit 
18. "/пробелы и pyc- Да К каталогу и его содержи- | Windows 32 ОЕМ 
ский/" мому bit 
19. smb://host/dir/ Да Только к каталогу Linux 32 bit OEM 
20. nul Да Windows 32 ОТЕ8 
bit 
21. "/пробелы и pyc- Нет Linux 32 bit OEM 
ский" 
22. host:/dir/ Да Только к каталогу Windows 64 ОТЕ8 
bit 
23. „ЛАГ Нет Windows 64 ОТЕ16 
bit 
24. ./dir/ HeT Linux 64 bit UTF16 
25. [257 байт только Нет Windows 32 ОТЕ16 
для Windows] bit 
26. "/пробелы и pyc- Нет Linux 64 bit UTF8 
ский/" 
27. Нет Windows 32 UTF8 
bit 
28. host:/dir/ HeT Linux 64 bit OEM 
29. Хлам Да К каталогу и его содержи- | Windows 64 ОТЕ8 
мому bit 
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30. \\ Да Ни к каталогу, ни K ero co- | Windows 64 ОТЕ8 
держимому bit 
31. // Нет Только к каталогу Windows 64 ОТЕ8 
bit 
32. ‚ЛА Нет Ни к каталогу, ни к его co- | Windows 64 | ОЕМ 
держимому bit 
33. Хлаіг Нет Только к каталогу Windows 64 | ОЕМ 
bit 
34. "Х\пробелы и pyc- | Да Только к каталогу Windows 64 ОТЕ16 
ский\" bit 
35. \\host\dir\ HeT Только к каталогу Windows 32 ОТЕ16 
bit 
36. [256 байт только Да К каталогу и его содержи- | Windows 32 ОТЕ8 
для Windows] мому bit 
37. [4096 байт только | HeT Только к каталогу Linux 64 bit UTF16 
ana Linux] 
38. /dir/ Да К каталогу и его содержи- | Linux 64 bit ОТЕ8 
мому 
39. [256 байт только Да К каталогу и его содержи- | Windows 64 | ОЕМ 
для Windows] мому bit 
40. Adir HeT К каталогу и ero содержи- | Windows 32 UTF16 
мому bit 
41. // Да Ни к каталогу, ни K ero co- | Windows 32 ОЕМ 
держимому bit 
42. prn Да Ни к каталогу, ни K ero co- | Windows 64 ОТЕ16 
держимому bit 
43. .\dir HeT Ни к каталогу, ни K ero co- | Windows 64 UTF16 
держимому bit 
44. \\host\dir\ HeT Только к каталогу Windows 64 ОТЕ16 
bit 
45. ../dir/ Да Ни к каталогу, ни к его co- | Linux 64 bit ОТЕ8 
держимому 
46. $ Да Только к каталогу Linux 32 bit OEM 
47. .\dir Да Только к каталогу Windows 32 ОТЕ8 
bit 
48. /dir Да Только к каталогу Linux 64 bit UTF8 
49. Е Нет Только к каталогу Windows 32 ОТЕ8 
bit 
50. ../dir/ HeT К каталогу и его содержи- | Linux 32 bit UTF16 
мому 
51. Adir Да Только к каталогу Windows 64 | ОЕМ 
bit 
52. host:/dir/ HeT Ни к каталогу, ни K ero co- | Linux 32 bit UTF16 
держимому 
53. "/пробелы и рус- Нет К каталогу и его содержи- | Linux 64 bit ОТЕ16 
ский" мому 
54. сот1-сот9 Да Ни к каталогу, ни K ero co- | Windows 64 ОТЕ16 
держимому bit 
55. lpt1-Ipt9 Да Только к каталогу Windows 32 ОТЕ8 
bit 
56. [0 символов] Нет Только к каталогу Linux 64 bit UTF16 
57. \\host\dir Да Ни к каталогу, ни к его co- | Windows 32 ОТЕ16 
держимому bit 
58. "Х\пробелы и pyc- | Да Только к каталогу Windows 64 ОТЕ16 
ский" bit 
59. \\host\dir HeT Только к каталогу Linux 64 bit UTF8 
60. lpt1-Ipt9 Да Только к каталогу Windows 64 ОТЕ8 
bit 
61. "Х\пробелы n pyc- | Нет К каталогу и его содержи- | Windows 32 ОЕМ 
ский" мому bit 
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62. һоѕї:/аіг Да К каталогу и его содержи- | Linux 32 bit ОЕМ 
мому 
63. ХА Да Только к каталогу Windows 32 ОЕМ 
bit 
64. \ Нет Только к каталогу Windows 32 ОЕМ 
bit 
65. [4096 байт только | Qa К каталогу и его содержи- | Linux 32 bit ОТЕ8 
для Linux] мому 
66. \\host\dir HeT К каталогу и его содержи- | Windows 64 | OEM 
мому bit 
67. Ы Нет Ни к каталогу, ни K ero co- | Linux 32 bit ОЕМ 
держимому 
68. соп Нет К каталогу и его содержи- | Windows 32 ОТЕ 16 
мому bit 
69. „ЛАТ Нет Только к каталогу Linux 32 bit UTF16 
70. Хлаіг Да К каталогу и его содержи- | Windows 32 ОЕМ 
мому bit 
71. ./dir Да К каталогу и его содержи- | Linux 32 bit ОТЕ16 
мому 
72. // Да К каталогу и его содержи- | Linux 32 bit ОТЕ16 
мому 
73. host:/dir HeT Ни к каталогу, ни K ero co- | Linux 64 bit UTF8 
держимому 
74. / Нет К каталогу и его содержи- | Linux 64 bit UTF8 
MOMY 
75. "Х\пробелы n pyc- | Да Ни к каталогу, ни K ero co- | Windows 32 ОЕМ 
ский\" держимому bit 
76. Adir\ Да Ни к каталогу, ни K ero co- | Windows 32 ОЕМ 
держимому bit 
77. |M HeT Только к каталогу Linux 64 bit OEM 
78. Хлам Да Только к каталогу Windows 32 ОТЕ8 
bit 
79. в Да Ни к каталогу, ни K ero co- | Linux 64 bit ОТЕ 16 
держимому 
80. / Да К каталогу и его содержи- | Linux 32 bit UTF16 
мому 
81. Да К каталогу и его содержи- | Windows 64 ОТЕ16 
мому bit 
82. com1-com9 Да Ни к каталогу, ни к его co- | Windows 32 ОЕМ 
держимому bit 
83. Да Ни к каталогу, ни K ero co- | Linux 64 bit OEM 
держимому 
84. /dir/ Да К каталогу и его содержи- | Linux 32 bit ОТЕ16 
мому 
85. [4097 байт только | Нет К каталогу и его содержи- | Linux 64 bit ОТЕ16 
для Linux] мому 
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4.5. Список основных определений 


Для удобства поиска термины приведены в алфавитном порядке со ссыл- 
ками на то место в книге, где находится их подробное рассмотрение. Здесь пред- 
ставлены только самые важные, самые ключевые определения из двух с лишним 
сотен, что рассмотрены в книге. 








Термин (по- Термин (по- Определение 
русски) английски) 
Автоматизиро- | Automated test- | Набор техник, подходов и инструментальных 
ванное тести- | тд средств, позволяющий исключить человека 
рование?з из выполнения некоторых задач в процессе 


тестирования. 








Альфа-тести- Alpha testing Тестирование, которое выполняется внутри 

рование* организации-разработчика с возможным ча- 
стичным привлечением конечных пользова- 
телей. Может являться формой внутреннего 
приёмочного тестирования. 

Анализ перво- | Root cause Процесс исследования и классификации пер- 

причин!250) analysis вопричин возникновения событий, негативно 


влияющих на безопасность, здоровье, окру- 
жающую среду, качество, надёжность и про- 
изводственный процесс. 





Бета-тестиро- 


Beta testing 


Тестирование, которое выполняется вне Op- 




















вание" ганизации-разработчика с активным привле- 
чением конечных пользователей/заказчиков. 
Граничное Border condi- Значение, находящееся на границе классов 
условие?“ tion, boundary | эквивалентности. 
condition 
Дефект!) Defect, anomaly | Отклонение фактического результата OT ожи- 
даний наблюдателя, сформированных на ос- 
нове требований, спецификаций, иной доку- 
ментации или опыта и здравого смысла. 
Динамическое | Dynamic testing | Тестирование с запуском кода на исполне- 
тестирова- ние. 
ние" 
Дымовое те- Smoke test Тестирование, которое направлено Ha npo- 
стирование?® верку самой главной, самой важной, самой 





ключевой функциональности, неработоспо- 
собность которой делает бессмысленной 
саму идею использования приложения (или 
иного объекта, подвергаемого дымовому те- 
стированию). 











Тестирование программного обеспечения. Базовый курс. 


© ЕРАМ Systems, 2015-2021 Стр: 293/298 


Список основных определений 








Инспекция 
(аудит) кода 


Code review, 
code inspection 


Семейство техник повышения качества кода 
за счет того, что в процессе создания или со- 
вершенствования кода участвуют несколько 
человек. В отличие от техник статического 
анализа кода (по потоку управления и потоку 
данных), аудит кода также улучшает такие 
его характеристики как понятность, поддер- 
живаемость, соответствие соглашениям об 
оформлении и т.д. Аудит кода выполняется в 
основном самими программистами. 





Интеграцион- 
ное тестирова- 
ние“ 


Integration test- 
ing 


Тестирование, которое направлено Ha npo- 
верку взаимодействия между несколькими 
частями приложения (каждая из которых, в 
свою очередь, проверена отдельно на стадии 
модульного тестирования). 





Класс эквива- 
лентности!2з4 


Equivalence 
class 


Набор данных, обрабатываемых одинаковым 
образом и приводящих к одинаковому ре- 
зультату. 





Метод белого 
ящика" 


White бох test- 
ing 


Метод тестирования, в рамках которого у те- 
стировщика есть доступ к внутренней струк- 
туре и коду приложения, а также есть доста- 
точно знаний для понимания увиденного. 





Метод серого 
ящика?" 


Gray бох testing 


Комбинация методов белого ящика и чёрного 
ящика, состоящая в том, что к части кода и 
архитектуры у тестировщика доступ есть, а к 
части — нет. (См. пояснения по альтернатив- 
ному определению здесь: {71}.) 





Метод чёрного 
ящика") 


Black box test- 
ing 


Метод тестирования, в рамках которого у TE- 
стировщика либо нет доступа к внутренней 
структуре и коду приложения, либо недоста- 
точно знаний для их понимания, либо он со- 
знательно не обращается к этим данным в 
процессе тестирования. 





Метрика?'° 


Меїгіс 


Числовая характеристика показателя каче- 
ства. Может включать описание способов 
оценки и анализа результата. 





Модель разра- 


Software Devel- 


Структура, систематизирующая различные 











ботки NON opment Model виды проектной деятельности, их взаимодей- 
ствие и последовательность в процессе раз- 
работки ПО. Выбор той или иной модели за- 
висит от масштаба и сложности проекта, 
предметной области, доступных ресурсов и 
множества других факторов. 

Модульное Unit testing, Тестирование, направленное на проверку от- 

(компонентное) | component test- | дельных небольших частей приложения, KO- 

тестирова- ing торые (как правило) можно исследовать n30- 

ние!“ лированно от других подобных частей. 

Набор тест- Test case suite, | Совокупность тест-кейсов, выбранных с HEKO- 

кейсов!" test suite, test торой общей целью или по некоторому об- 





ѕеї 





щему признаку. 
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Негативное те- 


Negative testing 


Тестирование, направленное на исследова- 








нальные требо- 
вания 


requirements 


стирование? ние работы приложения в ситуациях, когда с 
ним выполняются (некорректные) операции 
и/или используются данные, потенциально 
приводящие к ошибкам. 

Нефункцио- Non-functional | Тестирование, направленное на проверку He- 

нальное тести- | testing функциональных особенностей приложения 

рование 3 (корректность реализации нефункциональ- 
ных требований), таких как удобство исполь- 
зования, совместимость, производитель- 
ность, безопасность и т.д. 

Нефункцио- Non-functional Требования, описывающие свойства системы 


(удобство использования, безопасность, 
надёжность, расширяемость и т.д.), KOTO- 
рыми она должна обладать при реализации 
своего поведения. 








зультатах те- 
стирования?'” 


report, test sum- 
mary report 


Отчёт о ge- Defect report Документ, описывающий и приоритизирую- 

фекте! в” щий обнаруженный дефект, а также содей- 
ствующий его устранению. 

Отчёт о ре- Теѕї ргодгеѕѕ Документ, обобщающий результаты работ по 


тестированию и содержащий информацию, 
достаточную для соотнесения текущей ситуа- 
ции с тест-планом и принятия необходимых 
управленческих решений. 








Отчётность2% | Reporting Сбор и распространение информации o pe- 
зультатах работы (включая текущий статус, 
оценку прогресса и прогноз развития ситуа- 
ции). 

Планирова- Planning Непрерывный процесс принятия управленче- 

ние (206) ских решений и методической организации 


усилий по их реализации с целью обеспече- 
ния качества некоторого процесса на протя- 
жении длительного периода времени. 





Позитивное те- 
стирование”® 


Positive testing 


Тестирование, направленное Ha исследова- 
ние приложения в ситуации, когда все дей- 
ствия выполняются строго по инструкции без 
каких бы то ни было ошибок, отклонений, 
ввода неверных данных и т.д. 




















Покрытие?!2} Coverage Процентное выражение степени, в которой 
исследуемый элемент затронут соответству- 
ющим набором тест-кейсов. 

Приёмочное Acceptance Формализованное тестирование, направлен- 

тестирова- testing ное на проверку приложения C точки зрения 

ние“ конечного пользователя/заказчика и вынесе- 
ния решения о том, принимает ли заказчик 
работу у исполнителя (проектной команды). 

Расширенное Extended test Тестирование, направленное Ha исследова- 

тестирова- ние всей заявленной в требованиях функцио- 

ние! нальности — даже той, которая низко про- 


ранжирована по степени важности. 
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Регрессионное 
тестирова- 
ние“ 


Regression test- 
ing 


Тестирование, направленное на проверку 
того факта, что в ранее работоспособной 
функциональности не появились ошибки, вы- 
званные изменениями в приложении или 
среде его функционирования. 





Ручное тести- 
рование"?} 


Manual testing 


Тестирование, в котором тест-кейсы выпол- 
няются человеком вручную без использова- 
ния средств автоматизации. 





Системное те- 


System testing 


Тестирование, направленное на проверку 























под управле- 
нием поведе- 


testing 


стирование? всего приложения как единого целого, со- 
бранного из частей, проверенных на стадиях 
модульного и интеграционного тестирования. 

Статическое Static testing Тестирование без запуска кода на исполне- 

тестирова- ние. 

ние} 

Структурная Work break- Иерархическая декомпозиция объёмных 34- 

декомпози- down structure, | дач на всё более и более малые подзадачи с 

ция??? WBS целью упрощения оценки, планирования и 
мониторинга выполнения работы. 

Тести!” Test Набор из одного или нескольких тест-кейсов. 

Тестирование | Critical path test | Тестирование, направленное на исследова- 

критического ние функциональности, используемой типич- 

пути? ными пользователями в типичной повседнев- 
ной деятельности. 

Тестирование | Data-driven Способ разработки автоматизированных 

под управле- testing тест-кейсов, в котором входные данные и 

нием дан- ожидаемые результаты выносятся за пре- 

ными} делы тест-кейса и хранятся вне его — в 
файле, базе данных и т.д. 

Тестирование | Keyword-driven | Способ разработки автоматизированных 

под управле- testing тест-кейсов, в котором за пределы тест-кейса 

нием ключе- выносится не только набор входных данных 

выми сло- и ожидаемых результатов, но и логика пове- 

вами} дения тест-кейса, которая описывается клю- 
чевыми словами (командами). 

Тестирование | Behavior-driven | Способ разработки автоматизированных 


тест-кейсов, в котором основное внимание 
уделяется корректности работы бизнес-сце- 

















нием нариев, а не отдельным деталям функциони- 
рования приложения. 

Тестирование | Software testing | Процесс анализа программного средства и 

программного сопутствующей документации с целью выяв- 

обеспечения® ления дефектов и повышения качества про- 
дукта. 

Тестирование | Performance Исследование показателей скорости реакции 

производитель- | testing приложения на внешние воздействия при 

ности!) различной по характеру и интенсивности 


нагрузке. 
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Список основных определений 








Тест-кейси!” 


Test case 


Набор входных данных, условий выполнения 
и ожидаемых результатов, разработанный с 
целью проверки того или иного свойства или 
поведения программного средства. Под тест- 
кейсом также может пониматься соответству- 
ющий документ, представляющий формаль- 
ную запись тест-кейса. 





Тест-план208} 


Test plan 


Документ, описывающий и регламентирую- 
щий перечень работ по тестированию, а 
также соответствующие техники и подходы, 
стратегию, области ответственности, ре- 
сурсы, расписание и ключевые даты. 











ная декомпози- 
ynat”? 


composition 


Требование» | Requirement Описание того, какие функции и с соблюде- 
нием каких условий должно выполнять при- 
ложение в процессе решения полезной для 
пользователя задачи. 

Трудоза- Man-hours Количество рабочего времени, необходимого 

тратыг229 для выполнения работы (выражается в чело- 
веко-часах). 

Функциональ- Functional de- Процесс определения функции через её раз- 


деление на несколько низкоуровневых под- 
функций. 





Функциональ- 
ное тестирова- 
ние?} 


Functional test- 
ing 


Тестирование, направленное на проверку 
корректности работы функциональности при- 
ложения (корректность реализации функцио- 
нальных требований). 





Функциональ- 


Functional re- 


Требования, описывающие поведение cn- 














ные требова- quirements стемы, т.е. её действия (вычисления, преоб- 
ния разования, проверки, обработку и т.д.). 
Чек-лист!''2) Checklist Набор идей [тест-кейсов]. Последнее слово 


не зря взято в скобки, т.к. в общем случае 
чек-лист — это просто набор идей: идей по 
тестированию, идей по разработке, идей по 
планированию и управлению — любых 
идей. 
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Раздел 5: Лицензия и распространение 





Данная книга распространяется под лицензией «Creative Commons Attribu- 
Чоп-МопСоттегса|-ЗпагеА!Ке 4.0 International». 


Текст книги периодически обновляется и дорабатывается. Если вы хотите 
поделиться этой книгой, пожалуйста, делитесь ссылкой на самую актуальную вер- 
сию, доступную здесь: http://svyatoslav.biz/software_testing_book/. 


Задать вопросы, сообщить о найденных ошибках или поделиться впечатле- 
ниями от прочитанного можно по адресу stb@svyatoslav.biz. 


ххх 


Если вам понравилась эта книга, обратите внимание на ещё две, написанные 


в том же стиле: 


Работа с 

MySQL, MS SQL Server 
и Oracle 

| атн | 


РЕЛЯЦИОННЫЕ 
БАЗЫ 


ДАННЫХ 
| ети | 


Юа) LEARN 
Digital Platform 





«Работа c MySQL, MS SQL Server n Oracle в примерах» 


B книге: 3 СУБД, 50+ примеров, 130+ задач, 500+ запросов c no- 
яснениями и комментариями. От SELECT * до поиска кратчайшего 
пути в ориентированном графе; никакой теории, только схемы и 
код, много кода. Будет полезно тем, кто: когда-то изучал язык 
SQL, но многое забыл; имеет опыт работы с одним диалектом 
SQL, но хочет быстро переключиться на другой; хочет в пре- 
дельно сжатые сроки научиться писать типичные ЗОЁ-запросы. 


Скачать: http://svyatoslav.biz/database_book/ 
«Реляционные базы данных в примерах» 


Все ключевые идеи реляционных СУБД — от понятия данных до 
логики работы транзакций; фундаментальная теория и наглядная 
практика проектирования баз данных: таблицы, ключи, связи, 
нормальные формы, представления, триггеры, хранимые проце- 
дуры и многое другое в примерах. Книга будет полезна тем, кто: 
когда-то изучал базы данных, но что-то уже забыл; имеет узкий 
практический опыт, но хочет расширить знания; хочет в пре- 
дельно сжатые сроки начать использовать реляционные базы 
данных в своей работе.. 


Скачать: http://svyatoslav.biz/relational_databases__book/ 


В дополнение к тексту данной книги рекомендуется пройти бес- 
платный онлайн-курс, содержащий серию видео-уроков, тестов и 
заданий для самоподготовки. 


Курс рассчитан примерно на 100 часов, из которых около поло- 
вины времени у вас должно уйти на выполнение практических за- 
даний. 


С русскоязыяной озвучкой: http://svyatoslav.biz/urls/stc_online_rus/ 
С англоязычной озвучкой: http://svyatoslav.biz/urls/stc_online_eng/ 
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sa/4.0/legalcode] 
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